Re: C++ intermediate representation.

Chris F Clark <cfc@shell01.TheWorld.com>
14 May 2005 18:59:32 -0400

          From comp.compilers

Related articles
C++ intermediate representation. shakti.misra@wipro.com (DeltaOne) (2005-05-05)
Re: C++ intermediate representation. angray@beeb.net (Aaron Gray) (2005-05-13)
Re: C++ intermediate representation. cfc@shell01.TheWorld.com (Chris F Clark) (2005-05-14)
Re: C++ intermediate representation. henry@spsystems.net (2005-05-14)
Re: C++ intermediate representation. angray@beeb.net (Aaron Gray) (2005-05-14)
Re: C++ intermediate representation. ralphpboland@yahoo.com (Ralph Boland) (2005-05-14)
Re: C++ intermediate representation. cfc@shell01.TheWorld.com (Chris F Clark) (2005-05-14)
Re: C++ intermediate representation. gsc@zip.com.au (Sean Case) (2005-05-14)
Re: C++ intermediate representation. robert.hundt@gmail.com (Robert H) (2005-05-15)
Re: C++ intermediate representation. gdr@integrable-solutions.net (Gabriel Dos Reis) (2005-05-15)
Re: C++ intermediate representation. mefrill@yandex.ru (2005-05-15)
RE: C++ intermediate representation. quinn-j@shaw.ca (Quinn Tyler Jackson) (2005-05-15)
Re: C++ intermediate representation. comeau@panix.com (2005-05-15)
[5 later articles]
| List of all articles for this month |

From: Chris F Clark <cfc@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: 14 May 2005 18:59:32 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 05-05-023 05-05-068 05-05-077 05-05-087
Keywords: C++, parse, comment
Posted-Date: 14 May 2005 18:59:32 EDT

> 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]


Post a followup to this message

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