Re: C++ intermediate representation.

> Yes I am inclined to agree with you, but I have yet to see a GLR
> grammar for C++.


I'm certain the DMS people would be happy to sell you one. (A GLR C++
parser).


We have one (not GLR, but LR + predicates) for Yacc++ for the language
pre-templates (circa Cfront 2.0). Moreover, it was an exercise in
grammar inheritance, meaning we started with a K&R C grammar, made a
derived grammar that did ANSI C, and then a 2nd derived grammar that
did C++. Someday, I'll probably update it to process the current
dialect of the language. However, since no one has offered to buy
such a grammar. It will wait until I have done whatever I consider
more interesting.


As Quinn Tyler Jackson mentioned, he wrote one (backtracking LL) for
his tool Grammar Forge. He even made his job harder by doing it
without the normal "hacks" one allows oneself, doing it all within the
formal context of his tool.


As to commercial compilers, as I recall, a considerable number of them
use the EDG (Edison Design Group) front end, which is the defacto
standard at some level. This is your typical hand-coded recursive
descent. One of the reason it is widely used, is that "everyone else
uses it", meaning that even if it misparses C++ (not knowing that it
does), everyone's compiler misparses C++ in the same way, so you won't
have bugs unique to your platform.


The one thing that surprises me, given Stroustrup's statement about
building C++ with a yacc parser is how he made some of the design
mistakes he did. The syntax that uses parenthesis for passing
constructor arguments in a declaration, so that one cannot easily
distinguish a declaration of a variable that has constructor arguments
from a function prototype declaration is an example. That should have
caused his tool to give him conflicts, indicating that he was
wandering into an ambiguous grammar and should have found a different
syntax. Problems like this are why I try to steer people away from
hand-written recursive descent--one can easily write a parser that has
inconsistent rules by hand, expecially when one is prototyping and
adding extensions. The fact that Stroustrup was able to make the same
mistakes with a tool worries me extremely.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)


[I think the problem is that yacc tells you there's a bunch
shift/reduce conflicts and then produces a parser anyway for a
language not entirely different from the one in your grammar. Half
the time the shift resolution is what you want, half the time it's
not, but unless you understand LR parsing fairly well, it's hard to
look at the yacc output file and figure out what the problem was and
what it did. So it's tempting to hope that it's close enough and
blunder on ahead. -John]

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