Re: Proposal for study: Add a categorical Initial type to ocaml

From: John Prevost (
Date: Sun Oct 10 1999 - 00:43:35 MET DST

To: skaller <>
Subject: Re: Proposal for study: Add a categorical Initial type to ocaml
From: John Prevost <>
Date: 09 Oct 1999 18:43:35 -0400
In-Reply-To: skaller's message of "Sat, 09 Oct 1999 02:38:55 +1000"

skaller <> 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,
it's unsafe.

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