|Semantics make a grammar ambiguous firstname.lastname@example.org (Bill A) (1999-04-26)|
|Re: Semantics make a grammar ambiguous email@example.com (Robert Sherry) (1999-04-29)|
|Re: Semantics make a grammar ambiguous firstname.lastname@example.org (1999-04-30)|
|Re: Semantics make a grammar ambiguous email@example.com (Bill A.) (1999-04-30)|
|Re: Semantics make a grammar ambiguous firstname.lastname@example.org (Tzvetan Mikov) (1999-05-03)|
|Re: Semantics make a grammar ambiguous email@example.com (1999-05-07)|
|From:||"Tzvetan Mikov" <firstname.lastname@example.org>|
|Date:||3 May 1999 01:56:43 -0400|
|Organization:||Posted via RemarQ Communities, Inc.|
|Keywords:||C, parse, types|
Bill A wrote in message
>I'm having difficulty parsing this with an LALR parser (generated from
>a parser generator) because the second str should be an id but matches
>a typedef definition so a typedef terminal is returned from the lexer.
>What is the traditional way to handle this ambiguity? Is this a good
>case of why most production compilers are recursive decent?
To solve this problem I allow a typedef-name as well as an identifier
to appear in a declaration. I have written separate non-terminals for
declarations that allow redeclaring of a typedef-name and for ones
that don't. Each non-terminal has to be used selectively in the
context in order to avoid conflicts (for example you can't redeclare a
typedef-name in a declaration with implicit type). After quite a lot
of head-scratching now there is only one shift-reduce conflict in the
I don't think it is a good idea to feed the scanner with context-dependent
information - it could cause troubles with error recovery and generally I
think it could introduce obscure bugs.
Return to the
Search the comp.compilers archives again.