🚀 go-pugleaf

In article <913@m10ux.ATT.COM> mnc@m10ux.ATT.COM (Michael Condict) writes:
>In Pascal, there is only one way to interpret a given statement or declaration,
>regardless of any previous declarations.

>Consider the following in C, however:

>	. . . { T (x); . . . }

>How should the construct be parsed?  Is it the declaration of
>a variable x of type T (where T is a previously typedef'd identifier)?
>Or is it a call to the function T with argument x?
...
>To summarize, the only way you can parse C with a context-free parser is if
>you don't care whether a declaration is confused with an executable statement.
>This utterly destroys the usefullness of such a parse, as far as I'm concerned.

That may destroy the usefulness in your mind, but that does not make it
non-context-free.  To make a language recognizer (whose sole purpose
in life is to say "yes" this is a valid program, or "no" it is not)
you only need say yes or no for the whole program, not say what piece
is which.  C may very well be not context free, or not easily context
free, but this is based on things like making sure variables are declared,
the right type, etc. (i.e. only allow p->q->w if q is a pointer member
of a structure type p is a pointer to, and the type q points to has a
member w...)

The suggestion you make, of a rule like:

	decl_or_fcall	: identifier '(' identifier ')' ';' ;

to spot the case you mention works well. In fact it is a useful tool
for doing things like allowing forward-referenced typedefs.

>Michael Condict		{att|allegra}!m10ux!mnc
-- 
 Marc Mengel					mmengel@cuuxb.att.com
 						attmail!mmengel
 						...!{lll-crg|att}!cuuxb!mmengel