Re: LL Parser problem

Chris F Clark <>
7 Sep 2004 23:55:34 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: LL Parser problem (SM Ryan) (2004-08-11)
Re: LL Parser problem (Nick Roberts) (2004-08-13)
Re: LL Parser problem (Chris F Clark) (2004-08-15)
Re: LL Parser problem (Nick Roberts) (2004-08-23)
Re: LL Parser problem (Richard Pennington) (2004-08-25)
Re: LL Parser problem (2004-09-03)
Re: LL Parser problem (Chris F Clark) (2004-09-07)
| List of all articles for this month |

From: Chris F Clark <>
Newsgroups: comp.compilers
Date: 7 Sep 2004 23:55:34 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 04-08-121 04-09-006
Keywords: parse, design
Posted-Date: 07 Sep 2004 23:55:34 EDT

I agree with Dodi on the point:

> Wouldn't it be much better do design a simple and robust language and
> grammar in the first place...?

Yes, most languages should be mostly, if not entirely, LL(1) intersect
SLR(0). It makes life not only easier for parsers, but for human
comprehension also. (For example, recently I was considering
extending the regular expression syntax used in Yacc++ and was
considering something that would have made the precedence rules
non-trivial, in the name of "naturalness". Fortunately, my analysis
showed that simply getting the precedence right in the first place
made the non-trivial rules irrelevant and actually unnatural.) It's
relatively easy to achieve that goal also, starting each statement
with a unique type of token goes a long way in that regard.

As to his question:
n> I wonder what such parser generators are good for?

Unfortunately, the simple grammar perscription has long been ignored
and we have languages which are not only hard to parse, but embeddings
of languages within languages that compound these problems. Not good,
but a fact of life.


Chris Clark Internet :
Compiler Resources, Inc. Web Site :
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)

Post a followup to this message

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