Re: parser generator terminology

Michiel <mhelvens@gmail.com> writes:


> * An EBNF dialect, which automatically generates lists and optional
> values in the output language. Possibly the type of
> list<T>/optional<T> and the method for generating them may be
> specified separately from the grammar.


We did EBNF in Yacc++ at v. 1.0, and in 2.0 we did a construct
declaration which builds customized trees (ASTs) in a variety of user
defined (and builtin) shapes. It doesn't turn them into parameterized
types automatically, but it could.


> * Automatic location tracking. Again, with the code to do this
> specified separately from the grammar. In my Flex/Bison code, I'm
> finding the same couple of lines in virtually every rule.


That's near the top of the features we thought about adding. There is
some builtin support already, but it could be more automated. I think
ANTLR or JavaCC might have this already.


> * Parameterized grammar rules, to specify the same decoration for
> several constructs. For example:
>
> commalist(A): [ A { ',' A } ] ;
> formalparameters: commalist( type identifier ) ;
> tuple: '(' commalist( expression ) ')' ;
>
> would be equivalent to:
>
> formalparameters: [ type identifier { ',' type identifier } ] ;
> tuple: '(' [ expression { ',' expression } ] ')' ;
>
> I believe that with static analysis, such a grammar could always be
> automatically transformed to a grammar without parameterized rules.


Yes, it can be. That's farther down my list of things for Yacc++,
mostly because it can help people write harder to maintain grammars.
If you don't let the rules act like "captures", it gives you no power
that isn't already in an LR grammar. If you let the rules act like
captures, you end up in a different language class. (There is a paper
on IO and OI-languages which examines the implications in some detail
if I recall. That paper is in my archives in MA or I'd given you a
better title for it and an author.)


> * A way to output a human-readable grammar with documentation for
> grammar rules automatically extracted from the source-code.


Something like Doygen fro a grammar? Care to elaborate?


> Feel free to use or ignore these as you wish.


Sadly, it isn't lack of ideas keeping new things from going into
Yacc++, but lack of time/energy after my day job.


If you get motivated to implement some of this and want to yuse Yacc++
as a base, contact me and we can work something out.


> Good luck with your project.
>
> --
> Michiel Helvensteijn


Hope this helps,
-Chris


******************************************************************************
Chris Clark Internet: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. or: compres@world.std.com
23 Bailey Rd Web Site: http://world.std.com/~compres
Berlin, MA 01503 voice: (508) 435-5016
USA fax: (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

Return to the comp.compilers page.
Search the comp.compilers archives again.