Related articles |
---|
ll(1) and variable assignment... weltraum@astrocat.de (2004-11-06) |
Re: ll(1) and variable assignment... wyrmwif@tsoft.org (SM Ryan) (2004-11-07) |
Re: ll(1) and variable assignment... vbdis@aol.com (2004-11-07) |
Re: ll(1) and variable assignment... cfc@shell01.TheWorld.com (Chris F Clark) (2004-11-14) |
From: | vbdis@aol.com (VBDis) |
Newsgroups: | comp.compilers |
Date: | 7 Nov 2004 12:09:51 -0500 |
Organization: | AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com |
References: | 04-11-010 |
Keywords: | LL(1), parse |
Posted-Date: | 07 Nov 2004 12:09:51 EST |
weltraum@astrocat.de (Chris) schreibt:
>I want to write a recursive descent parser, and wonder if there is a
>LL(1) grammar for "c-style" variable assignement
>(i.e. "id=id=id+id" but not "id=id=id+id=2").
IMO the problem is the required lookahead in the very last production,
that can be a rvalue in the last place, or must be an lvalue if
followed by another "=".
In a typical solution the difference between rvalue and lvalue will be
handled on semantical level, not on syntactical level in the
grammar. Consider how fruitless a syntactical distinction between
rvalue and lvalue expressions is in practice, when a parser has to try
both ways anyhow. Parsing for an rvalue should always succeed, but
must result in a mismatch when a "=" follows. Likewise a parse for an
lvalue, in the first guess, will fail for most right hand sides of
such an assignment expression. Parsing for both rvalues and lvalues at
the same time is impossible in LL(1).
An LL(1) grammar for this case IMO is possible only with dramatic
restrictions, as that the lvalue grammar/language must be distinct
from the rvalue language, distinguishable by the very first token of
every expression.
DoDi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.