Problem Set 10
Languages for Object-oriented programming
This problem set is probably the most difficult one of the semester, but paradoxically, the one that asks you to write the least amount of code, and for which you should have to spend the least time programming, provided that you prepare before you start. In particular, you will need to gain a good mastery of the metacircular evaluator in section 4.1 of the notes--this material is critical, not only to this problem set, but to all of the material for the remainder of the semester.
This problem set has been designed so that the interpreter you will be dealing with is an extension of the metacircular evaluator. The implementation below is described with reference to the programs in the book. So in order to understand what is going on, it will be necessary to work through section 4.1 before starting on this assignment.
Instead of asking you to do a lot of implementation in this problem set, we are asking you to assume the role of language designer, and to think about and discuss some issues in the design of languages for object-oriented programming. Note especially that there is a significant part of this problem set to be completed after you have finished with the programming assignment.
Although Object-Oriented programming has become very popular, the
design of languages to support Object-Oriented programming is still an
area of active research. In this problem set, you will be dealing
with issues that are not well-understood, and around which there are
major disagreements among language designers. The questions in this
problem set will not ask you to supply ``right answers.'' Instead,
they will ask you to make reasonable design choices, and to be able to
defend these choices. We hope you will appreciate that, once you have
come to grips with the notion of an interpreter, you are in a position
to address major issues in language design, even issues that are at
the forefront of current research.
We've already seen two different approaches to implementing generic operations. One is data-directed programming, which relies on a table to dispatch based on the types of arguments. The second method, message-passing, represents objects as procedures with local state. As we saw in problem set 7, these objects can be arranged in complex inheritance relationships, such as ``a robot is a kind of person.''
One drawback with both of these approaches is that they make a distinction between generic operations and ordinary procedures, or between message-passing objects and ordinary data. This makes it awkward, for example, to extend an ordinary procedure so that it also works as a generic operation on new types of data. For instance, we might like to extend the addition operator + so that it can add two vectors, rather than having to define a separate vector-add procedure.
Object-oriented languages have attempted to integrate objects into the core of the language, rather than building an object system as an extension of a non-object language. In these object-oriented languages, every data type (object) belongs to a class, and there aren't really stand-alone procedures--but rather methods that are shared by various classes. This integrated approach was pioneered in the language Smalltalk, which was developed at Xerox PARC starting in 1971. This is also the approach used in Java.
The language we will implement in this problem set is called MIT TOOL (Tiny Object Oriented Language). It is most closely related to Dylan, a language developed at the at the (former) Apple Research Center in Cambridge. Dylan received a lot of attention when it was introduced in 1991, but its fortunes have waned (along with Apple's). MIT Tool is a very simplified version of Dylan, and it is designed to make the implementation an easy extension of the metacircular evaluator of chapter 4.