Dylan

It is worth looking at for a number of reasons:

• Apple are behind it - yet trying to promote it outside the company. They say: "We would be particularly interested in working with a group to create a reference implementation optimized for portability rather than performance, so that anyone could try out Dylan no matter what brand of computer they use. Because Dylan is a trademark of Apple Computer, anyone implementing the language must obtain permission to use the name. However, it is our intention that permission will be granted to anyone with a conforming implementation."
• The manual lists some requirements which the developers thought were sufficiently important to design a new language.
• It avoids some of the problems we have had with OO design.

The Dylan Interim Reference Manual of 3 June 1994 (180 KByte compressed postscript file) says:

... By letting programmers structure the text of their programs in terms of the problem at hand, object oriented programming narrows the gap between conception and realization. However, object oriented programming by itself is insufficient. ... The other half is provided by dynamism, yielding what Apple calls object oriented dynamic languages, or OODLs. In addition to supporting the object oriented methodology, OODLs must support a number of features which guarantee that programming takes place in terms defined by the programmer, rather than in the terms of the hardware.

OODLs must support rapid creation, delivery, and subsequent modification of ambitious, reliable, and efficient software...

Automatic Memory Management

Memory management bugs are among the most common and difficult errors in static programming languages. Bugs involving dangling pointers and twice-freed objects are notoriously hard to track down. The language run-time, and not the programmer, should be responsible for allocating storage for objects and reclaiming the storage of objects which are no longer used. There should be no explicit procedure calls for allocating or deallocating memory, or for deallocating objects... In a true OODL, there should be no machine-level pointers, only objects. Once freed from dealing with pointers, the programmer can begin to think of objects at a higher level and the primitives become comparably richer...

Dynamic Linking/ Incremental Development

Programmers should have the ability to build up their programs piece by piece, integrating preexisting pieces when possible and where available. The transition between rapid prototyping and mainstream development should be continuous rather than discrete. It should not require changing languages or tools...

Self Identifying Objects / Introspection

Operations should be checked for type safety before they are performed. If possible, this check should be performed at compile-time, otherwise it should be performed at run-time. This feature guarantees that type errors are noticed as soon as they occur, before they can propagate and cause system corruption. Because the integrity of the object model is maintained, error reporting can occur in terms of programmer objects and end-user objects, rather than in machine-level terms. In many cases, complete error recovery is possible. The language should contain features for introspection... For example, it should be possible at execution time to analyze the structure of an object, find the subclasses of a class, etc.

Object Oriented Programming Environment

The programming environment should present all debugging information at an object oriented level. Errors should be described in high-level terms similar to those used by the programmer in constructing the program. Inspection facilities should show a program as a collection of objects, not as a mass of undifferentiated bits. There should be tools for performance analysis and monitoring of single objects as well as collections of objects. There should be rich libraries of components, and the means to navigate within and between them and to organize and administer them...

It is not crazy

Many people in commercial industry and in the research community have recognized the problems with static languages, and some have started to build products that provide some of the features of OODLs... However, we believe that starting with a static language requires too many compromises... The common criticism of OODLs is that we cannot afford them. Most programmers view OODLs as slow and as memory hogs. The common wisdom is that OODLs do not make good use of machine resources. Fortunately, this view is out of date. The combination of improved OODL implementation technology and increasingly powerful hardware make OODLs eminently practical...

Some features of Dylan

• Classes form a DAG (multiple inheritance) rooted at <object>
• Dylan chooses the method to execute by looking at the types of all arguments. A consequence of this is that methods do not belong to classes - so normal OO design methods are not appropriate. N.B. add!(hit,flag,track) can be written track.add!(hit,flag)
• Classes have slots (data values) but storage and retrieval are both by methods which are not tied to the slot nor the class but are added to generic functions.
• Classes and functions are first class objects.
• Anonymous methods (lambda functions) are supported.
• Seems to have all properties of a functional language.
• Variables may be typed or not but must be declared.
• Methods may have have compulsory, optional and keyword parameters.
• All methods of a generic function must have "congruent parameter lists". The definition is quite tricky but it just makes sure that polymorphism works. For example they must have same number of required arguments and each of the method's parameter specializers is a subtype of the corresponding parameter specializer of the generic function.
• Method dispatch works by calling the most specific method.
• Lots of other good things
• The manual is quite heavy reading.