Re: Is C++ really used ?

> . . . There are some
> ways that a compiler makes very good use of the OOP paradigm. . . .


We had an OOPSLA workshop a couple of years ago on this topic and in
my opinion reached very similar conclussions. [The presentations used
to be at ftp://everest.ee.umn.edu/pub/oopsla, however, I believe that
site is no longer there.]


> Also the concept of sending an intermediate form node the message
> "type check yourself" or "generate code for yourself" required a
> rethinking of the traditional way of traversing the data structure
> for the intermediate-form.


There were at least two presentations on this specific aspect and I
think there is still some interesting work to be done here.


> There were two significant shortcomings in the OOP design of our compiler:
>
> 1) None of the popular parsing methods such as recursive descent,
> LL(1), and LALR(1), map well into an object-oriented design. The
> identification of the objects and the messages does not seem
> sensible for parsing.


If you mean, "should one parse by sending objects messages to
construct themselves" I agree. I have seen more than a few papers
attempting to create an object-oriented form of recursive descent. In
my opinion, the inverted flow of control that is natural with
object-oriented programming does not match well with the top-down
structure of recursive descent.


However, I think there are at least three ways that object-oriented
designs are a good match for parsing.


1) It is useful to model the entire parsing process as a set of
cooperating objects (i.e. lexer object, parser object, symbol table
object, input object, error reporting object, . . .). This makes it
very easy to use the compiler in non-traditional roles, and also
exposes some of the interdependencies between the modules allowing
them to be more easily customized. Barbara Zino (my partner) talked
specifically about those issues. I also remember other people talking
about their compiler frameworks and giving other motivations/benefits
for doing so.


2) Steve Johnson described a way to map parsing onto the construction
of objects and variants. The end result is that it is easy to think
of each rule in a grammar as associated with a class and each time
that rule is recognized by the parser an object of that class is
created. (Most poeple naturally do this when constructing an AST,
Steve simply suggested that the parser should do it for you more
automatically). My paper at the above workshop showed how to modify
that model to construct a variety of useful classes that match some
common parsing idioms (e.g. infix operators).


3) A grammar can also be viewed as a class, and it possible to build
families of compilers by "inheriting" rules (productions) between
grammars.


> In our course we just used Lex++ and Yacc++,
> and did not attempt any mapping to OOP principles.


And here, I hate to be a stickler, but I feel I must. The "yacc++"
you used was not "Yacc++(R) and the Language Objects Library", which
is a registered trademark of Compiler Resources, Inc. Because if you
had used it, you would have already been exposed to our religion on
the 3 points above (and hopefully would be one of our converts :-)).


-Chris Clark
--

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