OO Compiling: FOLLOW UP

Hello,
      A while back I posted a question regarding object oriented compiling.
Basically, I'm looking for a way to create an extensible language based on a
provided grammar. In reality, my problem is simpler than general OO
compiling: I have a language acting as an interface to a class library and I
want to be able to handle new subclasses to this library via the language.
Provisions exist for setting static and dynamic attributes, for producing code
that manipulates the objects, and for interfaces with provided functions /
global variables.
      I've decided to come up with a "general" language to act as a class library
interface. But I thought I would go ahead and summarize the responses I had
to my original query.




Urs Hoelzle (hoelzle@cs.stanford.EDU) and Jean-Marie Larcheveque
(jml@bdlyre.altair.fr) pointed out Gorel Hedin's (gorel@dna.lth.se) paper in
ECOOP'89. It has to do with OO attribute grammars. Jean-Marie provided the
following references:


@INPROCEEDINGS{Hedin89,
  AUTHOR = {G. Hedin},
  TITLE = {An object-oriented notation for attribute
grammars},
  BOOKTITLE = ECOOP89,
  YEAR = 1989,
  ABSTRACT = {Lots of copy rules and identical equations are
avoided by having some productions inherit equations from others;
the formalism is reminiscent of Mentor.} }




@INPROCEEDINGS{Borning82,
  AUTHOR = {Alan H. Borning and Daniel H. H. Ingalls},
  TITLE = {A type declaration and inference system for
{S}malltalk},
  BOOKTITLE = POPL82,
  YEAR = 1982,
  PAGES = {133-141},
  MONTH = {January},
  ABSTRACT = {Introduces a syntax for declaring types in Smalltalk. A type is
basically a class, except that concrete classes, like ``long integer'', which
do not specify the messages allowed but just a special implementation, are not
types, and a potentially infinite number of types may correspond to classes
like ``collection'', for example ``collection of:integer'', and so on. Type
inference is linked to type-checking. A syntax tree is built, and the message
executeForType is sent to a node (presumably the root, but this is not said),
which will in turn invoke the same message in related nodes. This amounts in
effect to attribute flow in a decorated tree, with the exception that the
effect of assignments to variables are cumulated (using the closest common
supertype) irrespective of control flow. In short, it is a nice simple
approach which incorporates minimal inferencing to complement type-checking.
It does not obtain results as precise as \cite{Suzuki81}, however. } }




Ralph Johnson (johnson@cs.uiuc.edu) had some illuminating
points. Quoting Ralph:


"That is more or less the way our Smalltalk compiler works. There is a class
for each non-terminal in the grammar. However, the methods of the classes
implement things like code generation and type inference, not parsing. You
can't invoke an object's methods until it is created, and you can't create an
object to represent a non-terminal until you have already parsed the input
string to figure out what kind of object you want. Our parsing is done with a
traditional recursive descent parser. This works well in an OOP language
because you can extend a grammar with inheritance by overriding the rules that
you want to change.


"Another problem with what you said is that new productions can have non-local
effects on parsing tables, so there is no way you can add new productions
without 'rebuilding the grammar as long as you are using traditional kinds of
tables for parsing. There area lot of parsing techniques that I don't know
about, so perhaps you are using one that is different, but that is something
that you have to watch out for."






Paul Steckler (steck@corwin.ccs.northeastern.edu) pointed me
towards Lieberherr's Demeter system. Quoting Paul:


"You may want to check out the spate of articles on the Demeter system
developed at Northeastern by Lieberherr et al.


"With Demeter, you define a class hierarchy with a grammar, and a parser
allows you to construct C++ objects defined by that grammar. You do have to
regenerate/recompile some code if the grammar is modified.


"Articles have been in OOPSLA proceedings, IEEE Computer."




Demeter related articles appear in OOPSLA 88 and 89, but these don't cover OO
compiling specifically. I have not inquired Lieberherr about the most recent
developments; after finals I plan to bother --er-- inquire Lieberherr about
Demeter.




Some replies mentioned Eiffel. I know how to spell Eiffel and that's about
the extent of my experience with it. I believe Bertrand Meyer's book _Object
Oriented Software Construction_ is supposed to be a good reference for Eiffel
(it's checked out here, so I'm supposing...).




I'm not sure how much documentation exists for yacc++ outside elusive
technical reports. The only article I've stumbled across so far is a general
review in the May 1991 issue of SunWorld, Vol. 4, No. 5, pp. 86-92 ("The
Domino Effect: Parsing and Lexing Objects with Yacc++"). yacc++ looks great.
Is there a bison++ yet?




I'm going to continue to collect information on this subject just so I can
compare and contrast my approach to it. As I get information, I will pass it
along to this group for consideration.


Eric Richards, Auburn University
InterNet: richards@eng.auburn.edu
--

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