C not LALR grammar

[COTTRELL, JAMES]

> >                        A ( *B );
> > 
> >     If A has been defined as a typedef name, then the line is a
> >     declaration of a variable B to be of type "pointer to A."
> >     (The parentheses surrounding "*B" are ignored.)  If A is not
> >     a type name, then this line is a call of the function A with
> >     the single parameter *B.  This ambiguity cannot be resolved
> >     grammatically.
> >         C compilers based on UNIX' YACC parser-generator -- such
> >     as the Portable C Compiler -- handle this problem by feeding
> >     information acquired during semantic analysis back to the
> >     lexer.  In fact, most C compilers do some typedef analysis
> >     during lexical analysis.
> 
> Which is just fine.  There are many other cases where the symbol
> table must be consulted to determine how to handle a construct
> (scope rules, etc.).  Nobody promised that C grammar would be
> strictly LALR(1)-parsable.  What is your problem?

Amen! At least it's not as bad as FORTRASH where when you see
the string `DO 10 I =' you don't have to look ahead for the comma
to tell you it's really a DO statement rather than an assign to the
variable `DO10I'. This freaked me out when I heard about it. YUK!

	jim		cottrell at nbs
*/
------