To: skaller <firstname.lastname@example.org>
Subject: Re: Proposal for study: Add a categorical Initial type to ocaml
From: John Prevost <email@example.com>
Date: 09 Oct 1999 18:43:35 -0400
In-Reply-To: skaller's message of "Sat, 09 Oct 1999 02:38:55 +1000"
skaller <firstname.lastname@example.org> writes:
> A better name than $ is probably 'none'.
> Boxed values can use a null pointer for none.
> Integers and floats can be treated as follows:
> do not initialise them at all, if -unsafe is
> specified. Otherwise, use the spare value of integers
> and some NaN for floats, and insert tests
> for all read accesses.
I have a question--how is this different (except for the efficiency of
using null) from using a 'a option array? The array still must be
initialized--in this case to all null, or in the unsafe case, well,
If anything, I would argue that this points at representing 'a option
specially for already boxed values by using a null pointer for None,
rather than having a special strange value that comes out of arrays
and magically creates exceptions.
One of the frustrations I have with things like Java is that it's not
possible to type references in a way which guarantees a value is not
With my proposal, your special thing turns into an 'a option array,
lookup is the same (but is not guaranteed to provide a Some value),
and there's a new array function:
val Array.make_with_option (or something) : unit -> 'a option array
which in some sort of "unsafe" mode doesn't actually initialize the
array and guarantee that all values are well-formed. This provides a
failure mechanism similar to unsafe array bounds, without adding
strange null values into the language.
Again, rather than introduce new features into the language, add a new
unsafe optimization and make the option type more efficient for boxed
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:26 MET