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