Re: Object-oriented compiler construction: ideas?

compres@world.std.com (Compiler Resources)
30 Jun 1996 16:34:57 -0400

          From comp.compilers

Related articles
[11 earlier articles]
Re: Object-oriented compiler construction: ideas? rwatson@CAM.ORG (Richard Edward Watson) (1996-06-23)
Re: Object-oriented compiler construction: ideas? bronnikov@aol.com (1996-06-24)
Re: Object-oriented compiler construction: ideas? bobduff@world.std.com (1996-06-26)
Re: Object-oriented compiler construction: ideas? leichter@smarts.com (Jerry Leichter) (1996-06-27)
Re: Object-oriented compiler construction: ideas? jgm@CS.Cornell.EDU (Greg Morrisett) (1996-06-27)
Re: Object-oriented compiler construction: ideas? cliffc@ami.sps.mot.com (1996-06-30)
Re: Object-oriented compiler construction: ideas? compres@world.std.com (1996-06-30)
Re: Object-oriented compiler construction: ideas? jdean@cs.washington.edu (1996-06-30)
Dynamic Attribute Grammars (was: Object-oriented compiler construction Martin.Jourdan@inria.fr (1996-07-01)
Re: Object-oriented compiler construction: ideas? solution@gate.net (1996-07-01)
Re: Object-oriented compiler construction: ideas? robison@kai.com (Arch Robison) (1996-07-01)
Re: Object-oriented compiler construction: ideas? mayan@watson.ibm.com (1996-07-02)
Re: Object-oriented compiler construction: ideas? pdonovan@netcom.com (1996-07-03)
| List of all articles for this month |

From: compres@world.std.com (Compiler Resources)
Newsgroups: comp.compilers
Date: 30 Jun 1996 16:34:57 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 96-06-047 96-06-064 96-06-117 96-06-134
Keywords: OOP

Robert A Duff wrote:
> That is, it seems to me that when you choose to use the Visitor pattern,
> you're basically saying that the OOP way is inappropriate in that
> particular case.
. . .
> Which technique is better depends in part on which parts of the system
> are likely to change -- are you going to add new classes, or add new
> operations?


In fact, the design patterns book [Gamma, et. al.] mentions that exact
trade-off.


One point in this regard is that if you do your AST as hierarchy of
classes, you can factor some of the questions you need to ask (e.g. is
this a binary operator) into the classes making your traversal passes
less fragile in the presence of changes to the grammar.


In response Greg Morrisett added:
> Another problem with the OO-approach is fixing the order of traversal
> in the Visitor pattern. In-order? Post-order? Pre-order? Visit
> right children first or left children? Depends a lot on the optimization
> or transformation you're performing. Perhaps this is the reason why
> attribute grammars and other forms of declarative tree/graph-rewriting
> seem attractive to compiler writers.


Yes, attribute grammars solve the ordering problem as long as there
are no circularities. Are there any systems which will allow
attributes that are transitive closures (i.e. what you would solve as
a dataflow analysis problem)?


Arch Robison presented a very good case for iterators to solve just
these problems at the 94 OOPSLA workshop of Object Oriented
Compilation techniques. His paper and others can be found at
ftp://ftp.parr-research.com/pub/oopsla.


More Greg:
> What we need are languages that allow programmers to view the organization
> or their programs in different ways in order to support different kinds
> of modifications. Ideally, when adding a new kind of primitive to the
> AST, the system would present the OO version, so that all I have to
> add is one new definition, with appropriate methods. But when I go to
> add a new transformation or optimization, I'd rather see the "old-
> fashioned" view of my program where I code one big procedure that
> switches on the different kinds of AST objects. This way, I don't have
> to touch all of the classes to add new methods.


The Dylan people from Harlequin claimed that they used multi-methods
to solve this problem at the same workshop.


Hope this helps,
Chris Clark


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. CompuServe : 74252,1375
85 Main Street, Suite 310 voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
--


Post a followup to this message

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