|LL(1)/Recursive Descent Parsing Question email@example.com (2002-03-19)|
|Re: LL(1)/Recursive Descent Parsing Question firstname.lastname@example.org (jacob navia) (2002-03-21)|
|Re: LL(1)/Recursive Descent Parsing Question email@example.com (Peter H. Froehlich) (2002-03-21)|
|Re: LL(1)/Recursive Descent Parsing Question firstname.lastname@example.org (Joachim Durchholz) (2002-03-22)|
|Re: LL(1)/Recursive Descent Parsing Question email@example.com (SLK Parsers) (2002-03-25)|
|From:||firstname.lastname@example.org (Neelakantan Krishnaswami)|
|Date:||19 Mar 2002 11:54:29 -0500|
|Posted-Date:||19 Mar 2002 11:54:29 EST|
I'm working on the syntax for a small programming language, and I'd
like to make sure that my language is parseable with an LL(1) grammar.
However, I'm still messing around with the grammar, and it's quite
unpleasant to have to write my grammar rules in an epsilon-free,
left-factored left-recursion-free form.
Is there an algorithm that will take a general context-free grammar,
and then computes an epsilon-free, left-factored, left-recursive
grammar from it if that is possible, and signals an error if it isn't?
If not, or if the algorithm is really complex, is there a restricted
extended BNF or regexp-like notation that can generate LL(1) grammars,
but which has operators to represent the most common programming
language constructions? Eg, I might write
sequence(start:RPAREN, element:<expr>, delimiter:COMMA, close:LPAREN)
to describe comma-separated tuples, and write the whole grammar using
constructions like this, counting on the restricted form of the
operators to ensure an easy translation into an LL(1) parser. Is this
a useful strategy?
Return to the
Search the comp.compilers archives again.