From:	"Christopher Nelson" <paradox AT gye DOT satnet DOT net>
To:	<djgpp AT delorie DOT com>
Subject:	Re: Bison and particular expressions.
Date:	Thu, 24 Jun 1999 11:39:03 -0600
Message-ID:	<01bebe68$744c8280$LocalHost@thendren>
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 4.71.1712.3
X-MimeOLE:	Produced By Microsoft MimeOLE V4.71.1712.3
Reply-To:	djgpp AT delorie DOT com

>> PS:  Am I trying to break LR grammar modes?  If so, is there any way to
>> resolve it?


>one rule looks like:
>D: parm ',' parm ','
>
>another rule (for a different token) is
>E: parm ',' ID ','
>
>The meanings of the symbols don't matter, only that they are derived
tokens,
>and ID is not the same as parm.
>The problem occurs after the first 'parm' is processed, by that time bison
has
>already decided what line it is on, but it chooses the wrong line and get's
a
>parse error when it encounters an ID instead of a 'parm'.  (It seems to
choose
>D even when E is a better match).
>
>Note:  both D and E have other rules.

make sure and look at what's below and above the tokens.  if they seem to
use the same operators for different tokens it can create a problem.   for
example, i'm building a scripting engine that does CSE on runtime code, but
i wanted immediate expressions (10+100-3) to be resolved at compile time by
the parser.  unfortunately, when i included the immediate-expression
evaluation code as a nonterminal into the runtime-expression evaluator, it
broke the code.  in other words,

a+10-115/3*b was no longer recognizable because after it recognized the
first variable, it tried to match the rest of the expression as an
immediate-expression.  but since b is not an immediate value, the parser
exits with an error.

i did eventually solve this error in one of my scripting languages so that
the expression can be resolved by the parser, but it was dirty.  the cleaner
way for me to do it was to eliminate the redundancy when i traverse the
syntax tree.

sorry for the long e-mail, but this is what i'm talking about.  if a
lower-level token uses some of the same operators that the higher-level
token does, it can confuse the parser.  another thing to remember is that
you should always put the longest desired match BEFORE the shorter ones.
e.g.:

E:  parm ',' parm ',' parm
|    parm ',' parm
;

depending on how the other tokens required for this expression were written,
putting the last line before the first line could cause the compiler to
never see a 3-operand expression, because a 3-op expression will also match
a 2-op expression.

this is equally true if the two rules belong to two different nonterminals
that join somewhere above.

    -={C}=-

- Raw text -