Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!rutgers!mit-eddie!uw-beaver!rice!titan!preston
From: preston@titan.rice.edu (Preston Briggs)
Newsgroups: comp.object
Subject: Re: OOD applied to interpreters and compilers
Keywords: OOD interpreters
Message-ID: <1858@brazos.Rice.edu>
Date: 2 Oct 89 20:08:45 GMT
References: <26873@genrad.UUCP>
Sender: root@rice.edu
Reply-To: preston@titan.rice.edu (Preston Briggs)
Organization: Rice University, Houston
Lines: 33

In article <26873@genrad.UUCP> charlie@genrad.com (Charlie D. Havener) writes:
>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. 

>Charlie Havener

It's no big deal.  There's lots of opportunities to do beautiful
OO things whith any large project, compilers included.
For an existance proof, see the Smalltalk system.

Compilers need symbol tables of various sorts.  Sounds like
a great object to me!  Need a syntax tree?  Another object.
A flow graph?  Another object.  Bit vectors (or more generally,
lattices)?  Another object.

In a nice system, I can imagine applying, very cleanly, all the
various graph manipulation and traversal algorithms to
my specialized graph objects.  In C, you invent some interesting
interlinking structure to represent a flow graph.  Then
you hack up a version of Tarjan's reducibility checker.  Then
you spend some days debugging it.  In a nice language,
I would subclass a more general, existing graph class, and
use the existing message, "reducible?" (or I'd like to someday).

Of course, it may run very slowly and take a lot of memory;
but the design part is still valid.  The implementation however
made need work.

Preston Briggs