Re: Should scanners see symbol table ? (was Re: Lookahead vs. Scanner Feedback) (Brian Bliss)
Fri, 10 Jan 92 19:15:17 GMT

          From comp.compilers

Related articles
Re: Lookahead vs. Scanner Feedback (1992-01-07)
Should scanners see symbol table ? (was Re: Lookahead vs. Scanner Feed (1992-01-08)
Re: Should scanners see symbol table ? (was Re: Lookahead vs. Scanner (1992-01-10)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Brian Bliss)
Keywords: parse, C
Organization: UIUC Center for Supercomputing Research and Development
References: 92-01-032 92-01-036
Date: Fri, 10 Jan 92 19:15:17 GMT

earlier I wrote:
>The fix to this problem is much easier than I first thought: Just use
>lex's right-context sensitivity operator (/) to search ahead in the input
>stream for one of [,{;] (preceeded by optional whitespace) when an
>identifier is encountered. In cases that match, always return the IDENT
>token; on cases that don't, lookup the name and return TYPE_NAME if the
>identifier is a typedef name, return IDENT otherwise.

This approach bombs on

/* empty declaration with only a typedef name */
typedef int foo;

and on

/* tag names */
typedef int foo;
struct foo var;

the latter can be solved as suggested earlier:

In article 92-01-032, writes:
|> [Reusing a typedef name] shouldn't be a problem, because this is not really
|> an ambiguous occurrence. You can deal with that by having a production
|> any_ident : ident | type_ident;
|> and using any_ident for the identifier in a declarator (and several other
|> places). This should be possible without introducing any ambiguities.

a scheme which will work for tag names and labels just fine,
but not names in the identifier space. writes:
|>So foo should be sent to the parser as an identifier token (with a way of
|>recovering the string (or a code for the string) from the token, and not
|>as type_identifier token or a label_identifier token

again, This can't be done without introducing ambiugities into the grammar.
(at least the grammar given in the back of K&RII) try introducting a
production typedef_name->T_IDENT and see how many shift reduce conflicts
you get.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.