Re: new language syntax

>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

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