|ITE bison grammar problem firstname.lastname@example.org (pmatos) (2005-06-04)|
|Re: ITE bison grammar problem email@example.com (pmatos) (2005-06-04)|
|Re: ITE bison grammar problem firstname.lastname@example.org (Carl Barron) (2005-06-05)|
|Re: ITE bison grammar problem bluemalov_NOSPAM_@hotmail.com (Andrew Wilson) (2005-06-05)|
|From:||"Andrew Wilson" <bluemalov_NOSPAM_@hotmail.com>|
|Date:||5 Jun 2005 11:26:46 -0400|
|Posted-Date:||05 Jun 2005 11:26:46 EDT|
As it stands this grammar is ambigious.
Is ite(id, id, id) an F or an E?
If you linked the lexical analysis stage to the symbol table, then you
could return id for undefined identifiers, eid for expression type
identifies, and fid for boolean identifiers. Replacing id with fid in
F, and eid with id in E will remove the ambigiouty.
%left '&' '+'
%token id fid eid
F: "ite" '(' F ',' F ',' F ')'
| F '&' F
M: E "==" E;
E: "ite" '(' F ',' E ',' E ')'
| E '+' E
On the other hand as the moderator noted, a better solutution would be
to parse a more general grammar and handle allowable types in the
semantic stages (could even handle it at runtime, but don't).
%nonassoc EQU // I would let the lexer capture the "==" sequence
%left '&' // I would personally give "and" a higher priority than "plus"
A: "ite" '(' A ',' A ',' A ')'
| A '&' A
| A '+' A
| A EQU A
> However, the real issue remains. There's a reduce/reduce conflict due
> to the ite and identifier. Since I can't syntactically distinguish
> identifiers, what should I do?
>> [My advice would be to treat them the same syntactically and sort
>> them out in the semantics. This lets you produce better error
>> messages like "boolean variable XYZ used for arithmetic" rather
>> than "syntax error". -John]
> How can I do that? Putting id only in F will permit id to be a
> condition in ite, and will make numerical vars impossible. Putting it
> only in E won't allow id to be a condition and won't allow us to have
> boolean variables.
> [Combine E and F, don't try to enforce types in the parser. -John]
Return to the
Search the comp.compilers archives again.