19 Mar 2002 11:54:29 -0500

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

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.