Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!ginosko!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!jpl-devvax!david
From: david@jpl-devvax.JPL.NASA.GOV (David E. Smyth)
Newsgroups: comp.object
Subject: Re: OOD applied to interpreters and compilers
Keywords: OOD interpreters
Message-ID: <6217@jpl-devvax.JPL.NASA.GOV>
Date: 12 Oct 89 21:59:37 GMT
References: <26873@genrad.UUCP>
Reply-To: david@jpl-devvax.JPL.NASA.GOV (David E. Smyth)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 52

In article <26873@genrad.UUCP> charlie@genrad.com (Charlie D. Havener) writes:
>The examples I have seen on Object Oriented Design apply 
>nicely to problems like graphic window systems and to problems
>in which there are real physical objects one can think about.
>It is not at all clear to me how to apply OOD or to use Object
>oriented programming style to the design of program language
>compilers or interpreters. 
>
>There seems to be a classic way to do these things, i.e. lexer-
>parser-code generator that is well established. 
>
>Can someone who is comfortable with OOD comment on its applicability
>to such problems? Is OOD a poor match to some problems? Will anyone
>admit it?

Actually, I've found that OOD and OOP works GREAT for implementing
compilers and interpreters.  I still use lex and yacc or similar tools,
but the action code in all cases deals with objects.  Its really very
clean:  A symbol table is a container of symbols, each of which are
objects:  some operations apply to symbol tables, some to symbols.  The
same operation applied to two different kinds of symbols may do
different things: "allocate space" for a floating point variable gives,
say, 4 bytes, for a boolean perhaps packs the bit into a word.

I talked with a few people implementing SOTA compilers last week at
OOPSLA and they have been finding the same thing:  for example,
instructions can generate their own bit patterns.  Note that Peter
Deutsch is renowned both for OO stuff (Smalltalk) and SOTA compilers.

The implementation of compiler concepts via encapsulation of code and
data (i.e., objects) allows the compiler to evolve easily: not only
does OOP work for a quick initial implementation, but the code is
easier to enhance to get a really good compiler over time.

I think that compiler implementation is one of the BEST places to use
OOD and OOP I have ever seen.

In fact, conceptually OOP is kinda like yacc generated compilers: the
actions are short, the methods are short.  The actions have a very well
constrained environment within which they are invoked, the methods on
an object are likewise very constrained and localized.

Try it, you'll like it.  I used C++ with yacc: just use methods and
instance variables, virtual functions, and single inheritance: "A
better C." Avoid the overloaded operators and multiple inheritance like
the plague, and you'll be productive very quickly.

Note that you really don't need to use C++, I'm actually gone "back" to
using C with structs for classes and instances.  OOP doen't require an
OOPL like C++ any more than structure programming required COBOL.  OOP
in C really works very easily, and I think gives me more control over
the resultant software (that's what I've always liked about C).