Related articles |
---|
Semantics make a grammar ambiguous bill@megahits.com (Bill A) (1999-04-26) |
Re: Semantics make a grammar ambiguous rsherry@home.com (Robert Sherry) (1999-04-29) |
Re: Semantics make a grammar ambiguous dplass@yahoo.com (1999-04-30) |
Re: Semantics make a grammar ambiguous bill@megahits.com (Bill A.) (1999-04-30) |
Re: Semantics make a grammar ambiguous mikov@usa.net (Tzvetan Mikov) (1999-05-03) |
Re: Semantics make a grammar ambiguous rkrayhawk@aol.com (1999-05-07) |
From: | "Tzvetan Mikov" <mikov@usa.net> |
Newsgroups: | comp.compilers |
Date: | 3 May 1999 01:56:43 -0400 |
Organization: | Posted via RemarQ Communities, Inc. |
References: | 99-04-087 |
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
grammar.
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.
regards,
Tzvetan
Return to the
comp.compilers page.
Search the
comp.compilers archives again.