Related articles |
---|
LL(1)/Recursive Descent Parsing Question neelk@alum.mit.edu (2002-03-19) |
Re: LL(1)/Recursive Descent Parsing Question jacob@jacob.remcomp.fr (jacob navia) (2002-03-21) |
Re: LL(1)/Recursive Descent Parsing Question pfroehli@ics.uci.edu (Peter H. Froehlich) (2002-03-21) |
Re: LL(1)/Recursive Descent Parsing Question joachim_d@gmx.de (Joachim Durchholz) (2002-03-22) |
Re: LL(1)/Recursive Descent Parsing Question dr_feriozi@prodigy.net (SLK Parsers) (2002-03-25) |
From: | neelk@alum.mit.edu (Neelakantan Krishnaswami) |
Newsgroups: | comp.compilers |
Date: | 19 Mar 2002 11:54:29 -0500 |
Organization: | ATT Broadband |
Keywords: | parse, question |
Posted-Date: | 19 Mar 2002 11:54:29 EST |
Hello,
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?
Neel
Return to the
comp.compilers page.
Search the
comp.compilers archives again.