Re: Ocaml 2 object system origins

[Didier.Remy@inria.fr]

> I just came across the paper "Typing in object-oriented languages:
> Achieving expressiveness and safety" by Kim Bruce, and was struck,
> once I referred back to the O'Caml documentation on the new object
> system, by the similarities.
> 
> So, I was just wondering whether the features of the new object system
> are based on this paper, a predecessor of this paper, or perhaps the
> language LOOM, which apparently shares syntax with the examples in the
> paper.

Dear John,

Not at all. You might read [3,4] (the Ocaml home page lists those under
"Related papers"). In particular [4] provides theoretical foundations for
O'Caml objects and a very brief comparison with LOOM.

More precisely, the design of O'Caml finds its origins in some of my earliest
works on type inference for extensible records [1, etc] and especially in an
experimental prototype called MLART described in [3].

In MLART, objects were not primitive but encoded, and a small OO in a
library was provided.  The OO library of MLART was about as expressive as
the OO constructs of O'Caml. It included multiple inheritance, binary
methods, etc. , and of course full type inference.  However, the lack of
syntactic sugar for classes and of an abbreviation mechanism made both
object types and typing errors unreadable.

Hence, an essential part of the design of O'Caml is its sophisticated use and
propagation of automatic abbreviations to keep type expressions relatively
small.  O'Caml also cut down a little on the expressiveness of the class
language of MLART, so as to improve readability of both types and typing
errors.  The OO layer of O'Caml is formally described in [4] except for the
recent redesign of the class language, which is inspired by [5].

The type system of O'Caml entirely relies on ML polymorphism.  The only
insignificant difference with ML is that types are taken modulo an
equational theory, and hence do not form a free algebra.  On the other hand,
the language LOOM uses a new notion called matching (<#) and primitive
self-types. It is folklore (but I don't think it has ever been checked
formally) that matching does not accomplish more than polymorphism over
row-variables.  As a result of this correspondence, the core languages
of LOOM and O'Caml have similar expressiveness. In particular, they both
handle binary methods, correctly.

However, there are several situations where O'Caml does much better than
LOOM.  An important difference is that O'Caml uses structural types, and
treats the type of self (almost) as any other type (and therefore classes
can abstract over the type of self). On the contrary, the type of self is a
primitive notion in LOOM, called "Mytype".  Some advanced examples such as
virtual types (that can be naturally defined in O'Caml ---see for instance
the subject/observer example in the documentation and in [7]) cannot be
written in LOOM. (However, a recent extension of LOOM with a notion of group
has been introduced to solve virtual types [6].)

Also, LOOM does not have multiple inheritance, but this could be added quite
easily.  LOOM does not have type-inference, which is, of course a major
difference.

> (The presence of # types seems too much to be chance.)

As Jerome said, we choice the same symbol as the one used for hash-types in
LOOM because of the resemblance. However, O'Caml #-types are regular types
(this is just a notation for an implicit row-variable) while hash-types are
a primitive notion in LOOM.

Best regards,

        -Didier

----------------

See <http://cristal.inria.fr/~remy/publications.html> for details.

[1] Type Inference for Records in a Natural Extension of ML. 

[3] Programming Objects with ML-ART: An extension to ML with Abstract and
Record Types.

[4] Objective ML: An effective object-oriented extension to ML.  (with
Jérôme Vouillon).

[5] Using modules as classes by Jérôme Vouillon.
<http://cristal.inria.fr/~vouillon/publi.html>

[6] Semantics-Driven Language Design: Statically type-safe virtual types in
object-oriented languages by Kim B. Bruce and Joseph Vanderwaart.
<http://www.cs.williams.edu/~kim/README.html>

[7] The reality of virtual types for free! (with Jérôme Vouillon).