Re: new language syntax

wclodius@aol.com (Wclodius)
20 Oct 2001 21:53:34 -0400

          From comp.compilers

Related articles
new language syntax aberegov@home.com (Aleksey Beregov) (2001-08-24)
Re: new language syntax remove.haberg@matematik.su.se (2001-08-25)
Re: new language syntax 04lzvud73001@sneakemail.com (2001-08-25)
Re: new language syntax svdh@wanadoo.fr (2001-09-21)
Re: new language syntax howard.s.modell@boeing.com (HSM) (2001-09-25)
Re: new language syntax rboland@unb.ca (Ralph Boland) (2001-09-26)
Re: new language syntax joachim_d@gmx.de (Joachim Durchholz) (2001-10-06)
Re: new language syntax wclodius@aol.com (2001-10-20)
Re: new language syntax cfc@world.std.com (Chris F Clark) (2001-11-05)
| List of all articles for this month |

From: wclodius@aol.com (Wclodius)
Newsgroups: comp.compilers
Date: 20 Oct 2001 21:53:34 -0400
Organization: AOL http://www.aol.com
References: 01-10-019
Keywords: parse, design
Posted-Date: 20 Oct 2001 21:53:34 EDT

>Ralph Boland <rboland@unb.ca> wrote:
>>
>> The parser generated should be LALR(1) or LR(1). (A Must) There
>> shouldn't be any clever tricks to get around grammars that are not
>> LR(1). If I can't write a LR(1) grammar for my application I lose.


There are tradeoffs here that are not always obvious. The more
flexibility your tool allows the easier it is for you to create
grammars that are difficult for the users to understand. The more
flexible the tool is the more obscure are the problems with the
grammars that it can't understand and the more difficult it is to
debug the grammar when problems are encountered. As a result many
posters here will often recommend using the least flexible tool in
creating your own language, and reliance on more flexible tools only
for established more complex languages. In the worst cases, devope a
recursive ddesceent parseer.


Be aware that few tools are LR(1). Most are probably LALR(1) with
extensions. LALR(1) allows only a difficult to describe subset of
LR(1), and can produce verry obscure error messages for grammars that
are LR(1) but not LALR(1). The extensions often allow grammars that
aren't LR(k) for finite k, i.e., automatic treatment of the dangling
ELSE problem.


William B. Clodius


Post a followup to this message

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