Re: Should scanners see symbol table ? (was Re: Lookahead vs. Scanner Feedback)

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;
foo;


and on


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


the latter can be solved as suggested earlier:


In article 92-01-032, smk@dcs.edinburgh.ac.uk 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.


blakemor@software.org 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.


bb
--

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