From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA14548 for caml-redistribution; Sun, 24 Jan 1999 22:40:10 +0100 (MET) 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 WAA10255 for ; Sun, 24 Jan 1999 22:36:46 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA10955; Sun, 24 Jan 1999 22:36:44 +0100 (MET) Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA13264; Sun, 24 Jan 1999 22:36:45 +0100 (MET) From: Pierre Weis Message-Id: <199901242136.WAA13264@pauillac.inria.fr> Subject: Re: Array interface question To: Jerome.Vouillon@inria.fr (Jerome Vouillon) Date: Sun, 24 Jan 1999 22:36:45 +0100 (MET) Cc: caml-list@inria.fr In-Reply-To: <19990124164403.11999@pauillac.inria.fr> from "Jerome Vouillon" at Jan 24, 99 04:44:03 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: weis > > Perhaps the solution is to have an improved implementation of the 'a > > option type, where a NULL pointer would mean "None" and anything else > > would be the element of type 'a. > > > > Is there anything wrong with this approach? [except that it could break > > some interfaced C code that relies on NULL pointers in "private" types..] > > The problem is that you need to be able to differentiate None from > Some None, Some (Some None), ... > > -- Jerome Exactly, even if nobody thinks to write this kind of strange expressions, the option datatype is powerful enough to represent arithmetic. On the other hand, the problem of NULL pointers is easy to solve: we just need a unique object to represent None, and this object has not to be NULL, and in fact it cannot be 0, if we want to differentiate None and Some 0 (Some being supposedly omitted). (An Atom in terms of the Caml memory manager would perfect for this purpose). The Some (Some ...) problem could be solve if option where not only a datatype but ... an option of record field names (or even constructor names), analoguous to the mutable annotation for record fields. You could write type person = { option name : string; option age : int};; This way the None values can be introduced by the compiler when building a value of type person, for each optional field with no associated value. The Some constructors would be ommitted from the representation as desired. At pattern matching you may write None as a valid pattern for an optional field, and write the normal expected pattern otherwise (no need to write a Some constructor). In addition, you could set once an optional field with some value, the compiler checking that this field is indeed None before setting the new value. This is absolutely similar to the mutable annotation that was introduced to avoid the systematic insertion of reference cells in records, hence leading to mutable values without extra indirections (and more intuitive typings in my mind). The introduction of the notion of ``option'' at the langage level would lead to the same advantages: more compact representation of values, more natural handling of the notion, especially for construction of values, pattern matching, and typing. Pierre Weis INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/