LL(1)/Recursive Descent Parsing Question

neelk@alum.mit.edu (Neelakantan Krishnaswami)
19 Mar 2002 11:54:29 -0500

          From comp.compilers

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)
| List of all articles for this month |

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


Post a followup to this message

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