On Thu, 2007-09-27 at 13:21 -0700, Erick Tryzelaar wrote:
> This paper [1] came around on LtU recently [2]. It has some
> interesting ideas for the grammar patterns that skaller talked about a
> while ago. It seems to have a lot of similar philosophies to our
> embedded syntax language. It looks like they even use an embedded
> scheme-like language as their production language.
>
> [1]: http://www.cs.ucla.edu/~awarth/papers/dls07.pdf
> [2]: http://lambda-the-ultimate.org/node/2477
>
>
> It looks like it has a couple nice features. First off, non-terminals
> can be named. So, you can do this
>
> exp ::=
> | <exp>:x '+' <fac>:y => '(+ ,x ,y)
> | <exp>:x '-' <fac>:y => '(- ,x ,y)
> | <fac>
> ;
>
> It could be handy since I always end up having to count the
> non-terminals in a grammar in order to do $5 or something.
There is a reason Felix Elkhound grammars allow this and the
Dypgen ones do not: the way I have implemented the Scheme rules,
they are executed in a 'context' in which _1 _2 _3 .. etc are
defined. To compile them all before actually parsing for
performance, a global context with _1 .. _50 is used.
Adding names to the context is not possible, because the
scheme terms are already compiled against it.
A solution is to wrap the scheme string X in
(let ((exp _1)(fac _3)
X
)
where Felix calculates the wrapper. So it can be done.
> Second, it also allows for parameterized productions. This allows you
> to do something like:
>
> listOf p ::= <apply p> {',' <apply p>}*;
>
> where the p in <apply p> is a higher order function and the apply is
> just calling the p function.
Felix can and does that right now:
X*
X+
X?
are examples of meta-productions. But you can't define your
own at this stage, if only because I can't think of a syntax
for using it if you did. The list example you give above is precisely
the motivating example: I could easily implement
xlist := listof , x =># ...
but who the heck could read that?? The problem isn't defining
a higher order production like 'listof', but using it.
Well, defining it is a bit tricky too .. a few hours ago I appealed
on comp.lang.scheme for a scheme programmer to help us.
Basically what we have is a FIRST ORDER system, where the user
can define their own productions to generate ASTs, but they
can't extend the syntax used to define syntax: that's a
SECOND order system.
The problem here is that we ALREADY parse the syntax extension
syntax in a way that can ALREADY be extended with new
grammar productions -- Dypgen is extensible, full stop ..
but there is no way to write the user actions to expand
the parsed meta-productions into actual productions.
For X*, X+ etc I have done that in Ocaml, so the pattern
is there .. the basic parts of that needed to be made
available as Scheme commands, so that Scheme code can
be used to implement the extensions.
> Finally, they have grammar classes. We might already be doing this,
> but I'm not positive. This lets you define a simple grammar, then
> replace bits and pieces of it in a subclass grammar.
That is better than what Dypgen does, but still wrong.
Dypgen allows transient (scoped) modifications.
These can be propagated, but if not, they're lost
at the end of the scope .. in effect this is subclassing.
Felix doesn't let you delete productions, which would be
needed to replace them, but Dypgen does.
But it is wrong, and so is OMeta. Overriding is weak,
there is a know better technique: open recursion.
Overriding has the well known problem called the covariance
problem.
For an example of open recursion, see flx_types.mli,
the definitions of btypecode0_t, bytypecode_t:
this uses open recursion with two fixations. This is necessary
to ensure that the recursive typing is properly extended.
You CAN do that with objects .. but only for ONE parameter,
the object's class.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
