From: Pierre Weis <Pierre.Weis@inria.fr>
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)
In-Reply-To: <19990124164403.11999@pauillac.inria.fr> from "Jerome Vouillon" at Jan 24, 99 04:44:03 pm
> > 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/
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:18 MET