FYI:

My favorite parser-generator is ProGrammar from http://www.programmar.com/. It's not open source or free, but it is inexpensive, LL(n), and can examine the parse tree in productions, making it a linear bounded automata! Alas, it does not generate source, but a proprietary grammar file. You have to link to a supplied .lib or use the ActiveX. Currently available for Windows, but I have an alpha for Linux that works fine. This one builds a parse tree and provides an API to walk it and extract data. Its for C/C++, VB, Delphi.

I've used an LALR parser-generater in the past. I would never consider using Bison or anything that's not LL(n) again.

Bruce

In article <9s6s97$2bem$1@digitaldaemon.com>, Sean L. Palmer says...
>
>Antlr is evidently Public Domain:
>
>http://www.antlr.org/rights.html
>
>Sean
>
>"Axel Kittenberger" <axel@dtone.org> wrote in message news:9s5d02$11j9$1@digitaldaemon.com...
>> > If it's at all possible, I'd recommend making D have an LL(k) grammar
>for
>> > some small k, as this will vastly simplify the parser needed and allow
>> > alot
>> > more tools to manipulate D code.  Please don't force people to use
>> > LEX/YACC
>> > to parse D.  My script languages have always been LL(2) or LL(1) and I
>can
>> > get away with coding the parser by hand.  I think Antlr generates LL(k)
>> > parsers too.
>>
>> Do you know any OpenSource LL(n) parser generators for C?
>>
>> - Axel
>> --
>> |D) http://www.dtone.org
>>
>
>

"Sean L. Palmer" wrote:

> If it's at all possible, I'd recommend making D have an LL(k) grammar for
> some small k, as this will vastly simplify the parser needed and allow alot
> more tools to manipulate D code.  Please don't force people to use LEX/YACC
> to parse D.  My script languages have always been LL(2) or LL(1) and I can
> get away with coding the parser by hand.  I think Antlr generates LL(k)
> parsers too.

I don't think that LL(k) is possible (without hacks).  The problem is the
following:

    <identifier> ****...*** <identifier>

Note that there could be any number of *'s.  At this point, a parser CANNOT
determine how to parse it.  Is it the beginning of a declaration, or it is an
expression?  If it is a type, then it should be parsed as:
    (((((...((<identifier> *) *) ... *) *) *) *) *) <identifier>
but if it is an expression, then the first * is a multiplication, and the rest
are dereferencing operators:
    ( <identifier> * (* (* (* ... (* (* <identifier> ))...))))

Obviously, it is legal for that string of *'s to be arbitrarily long.  Thus, in order to write an LL(k) parser, you have to parse a rule that matches an arbitrarily long string of *'s, and then use that either in an expression or a declaration.  It's conceivable, but ugly.

I proposed an alternate declaration syntax (move the *'s to the left) that would
eliminate this problem.  I think that it might make D LALR(2)...

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]