Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!usc!sdsu!bionet!agate!shelby!portia!dchapman
From: dchapman@portia.Stanford.EDU (David Chapman)
Newsgroups: comp.object
Subject: Re: OOD applied to interpreters and compilers
Keywords: OOD interpreters
Message-ID: <5472@portia.Stanford.EDU>
Date: 3 Oct 89 06:28:17 GMT
References: <26873@genrad.UUCP>
Sender: David Chapman 
Reply-To: dchapman@Portia.Stanford.EDU (David Chapman)
Organization: Stanford University
Lines: 42

In article <26873@genrad.UUCP> charlie@genrad.com (Charlie D. Havener) writes:
> [Can OOD be used for compilers and interpreters?]

Sure.  I'm working on a compiler for an internal language that has two
different code generators.  I defined a "code generator" interface (the
language, MAINSAIL, isn't quite object-oriented in the sense that
Smalltalk or C++ are) and wrote two different modules that implemented
that interface.

The primary reason that you don't think in terms of objects for
something like a compiler is that you only have _one_ of the "objects"
at a time - one lexical analyzer feeds one parser feeds one optimizer
feeds one code generator.

On the other hand, if you wrote a compiler in the way that the FORTH
language is defined - as a set of words to call, such that the parsing
function (for example) is distributed among the words, you could define
a powerful and easily extendible (if unconventional) compiler.  I've
thought of doing it myself (one of these days; it's number 973 on my
list of things to do :-).

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

These are "classic" examples in much the way that you noted there is a
classic way of writing compilers and interpreters.  That abstract
examples do not exist yet is more a function of the relative newness of
OOP, in my opinion.

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

There is real power in just about any programming technique you want to
try - procedural (Pascal, C); functional (LISP, APL); logical (PROLOG);
or object-oriented.  Which works best?  Whichever one you yourself are
most comfortable with and find easiest to use.  Why learn new ones?  You
might find that a new paradigm fits your style of thinking better.  I'm
slowly shifting from procedural languages to object-oriented ones.  Using
C++ makes that transition easier for me, but that's personal preference
only and I won't criticize your choice of language.