From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA16984 for caml-redistribution; Tue, 14 Sep 1999 09:21:11 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA00651 for ; Mon, 13 Sep 1999 15:16:14 +0200 (MET DST) Received: from morgon.inria.fr (morgon.inria.fr [128.93.8.33]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id PAA03712; Mon, 13 Sep 1999 15:15:57 +0200 (MET DST) Received: (from remy@localhost) by morgon.inria.fr (8.8.7/8.8.7) id PAA03616; Mon, 13 Sep 1999 15:15:57 +0200 Message-ID: <19990913151557.26714@morgon.inria.fr> Date: Mon, 13 Sep 1999 15:15:57 +0200 From: Didier.Remy@inria.fr To: John Prevost Cc: caml-list@inria.fr, Kim Bruce Subject: Re: Ocaml 2 object system origins Reply-To: Didier.Remy@inria.fr References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.85e In-Reply-To: ; from John Prevost on Mon, Sep 06, 1999 at 06:38:32AM -0400 Organization: INRIA, BP 105, F-78153 Le Chesnay Cedex Phone: (33) 1 3963 5317 -- Sec: (33) 1 3963 5570 -- Fax: (33) 1 3963 5684 Web: http://cristal.inria.fr/~remy Sender: weis > 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 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. [6] Semantics-Driven Language Design: Statically type-safe virtual types in object-oriented languages by Kim B. Bruce and Joseph Vanderwaart. [7] The reality of virtual types for free! (with Jérôme Vouillon).