Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ig!arizona!kwalker
From: kwalker@arizona.edu (Kenneth Walker)
Newsgroups: comp.lang.misc
Subject: Re: Language Design, or: is C's Grammar Context Free
Keywords: BNF, Grammars, Silliness
Message-ID: <10210@megaron.arizona.edu>
Date: 13 Apr 89 01:45:26 GMT
References: <5200040@m.cs.uiuc.edu> <12443@watdragon.waterloo.edu> <9313@dasys1.UUCP>
Organization: U of Arizona CS Dept, Tucson
Lines: 27

In article <9313@dasys1.UUCP>, aj-mberg@dasys1.UUCP (Micha Berger) writes:
> 
> I don't see any qualitative difference between typedef's and variable
> decleration. An identifier is an identifier. Are you going to tell me
> that Pascal isn't CF because A*B could have diffent meanings, because
> multiplying integers creates different code than multiplynig reals?

The difference is, at least in part, one of practicality. The parse of
A*B is useful for generating code for either integer or real multiplication.
However, I really want my parser to tell the difference between a
declaration and a statement. If you think you would be happy waiting
until the parser is done to decide, be my guest and try it (you will have
to decide what the grammar needs to look like first). The purpose of
a grammar based parser is to take a big chunk out of the complexity 
of program analysis. There is still plenty of work left when it is done,
so the more it can do the better!

Some people have claimed that parsing C is easy. How many of you have
actually tried to produce a _useful_ parser for full ANSI Standard C?
I did it using YACC and the trick of feeding a symbol table back into
the lexical analyser, but it wasn't fun. A corollary of Murphy's Law:
there is a direct relationship between ignorance and optimism. (Which
seems to explain why I usually underestimate how long projects will
take.)

   Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
   +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker