Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!arc!steve From: steve@arc.UUCP (Steve Savitzky) Newsgroups: comp.object Subject: Re: OOD applied to interpreters and compilers Keywords: OOD interpreters Message-ID: <586@arc.UUCP> Date: 2 Oct 89 20:05:44 GMT References: <26873@genrad.UUCP> Reply-To: steve@arc.UUCP (Steve Savitzky) Organization: Advansoft Research Corp, Santa Clara, 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? Well, the last time I wrote a Smalltalkish byte compiler, there were three obvious candidates for "physical" objects: the lexer, the syntax productions and the abstract syntax trees. Basically, you do something like: (Program parse: aStream tokenize) emitCode i.e. first you tell a character stream to pass you back a stream of tokens, then you tell the top-level production to parse the tokens, then you tell the root of the resulting tree to emit some code. You may end up using the same set of classes for both syntax and semantics; i.e. the *class* Expression may parse an input stream, producing an *instance* of Expression in the process. As for interpreters, that's basically what a Lisp interpreter does: take an Expression object and send it the message "value". You can refine this by having different subclasses of Expression like If, For, and so on. An interpreter written this way will typically run slower than one that takes the "standard" approach of compiling into byte codes or machine language, but has advantages for debugging, algorithm animation, and the like. Actually, it may run faster if things evaluate themselves by performing incremental compilation. >Comments pro and con appreciated, thanks >Charlie Havener GenRad Inc. (508-369-4400 x3302) charlie@genrad.com You're welcome. -- Steve Savitzky | steve@arc.uucp | apple.com!arc!steve ADVANsoft Research Corp. | (408) 727-3357(w) / 294-6492(h) 4301 Great America Parkway | #includeSanta Clara, CA 95054 | May the Source be with you!