Re: References to object oriented design of compilers?

wjw@eb.ele.tue.nl (Willem Jan Withagen) writes:


>I'm not really all that Object-oriented, so forgive me if I'm besides the
>point. [ Usually I'm of the opinion that OO is not in the language, but
>in the usuage. Making it possible to do OO stuff in more that just the
>traditional OO languages ]


Certainly. It is easier to do object-oriented programming in an
object-oriented language, but you can do it in any language. Many systems
that are not written in object-oriented languages are object-oriented. I
assume that AG and PUMA fit into this category.


johno@lucinda.lat.oz.au (John Ophel) writes:
> Interesting. The basic argument for object oriented design as been that an
> object should contain the methods that relate to that object, thus
> encouraging modular design. The above example describes a situation where
> we don't want the methods relating to an object contained in the object
> but stored separately on a per function basis. By using double dispatching
> and complicated structure we can have a solution that would be more
> naturally expressed in a function-oriented solution.


Like all generalizations, the "basic argument" has exceptions. This is
one of them. I was explaining how to build ASTs in an OO language. I
wasn't claiming that this was the best use of an OO language. In fact, I
think that parsing and abstract syntax trees is NOT the most important use
of an OO language in a compiler. The optimization phase is much better,
where you have to keep track of complex dependences between different
parts of the program. OOP lets you encapsulate these complex data
structures and simplifies the programs that act upon them.


The general problem is that it is hard to write, say, half your program in
ML and half in C++ or Smalltalk. So you have to pick a language and use
it for parts of the system for which it is less than perfectly suited. It
is fairly common for OO systems to have parts of them that are primarily
functional or that are pattern-matching. The implementation of
"functions" and "patterns" will be done in the OO language and then the
programmer will think of the application in terms of these lower-level
objects. The result is that the design of parts of the system is not
object-oriented even though the underlying programming language is.


The proper question for this newsgroup is what paradigm is best for
each of the various parts of the compiler. Parsers should be generated
from grammars. Computing attributes on ASTs is best done functionally.
I claim that manipulating a program in Static Single Assignment form,
or something similar, is best done with objects. What are other parts,
and which paradigm is best for them?


-Ralph Johnson
--

Return to the comp.compilers page.
Search the comp.compilers archives again.