Version française
Home     About     Download     Resources     Contact us    
Browse thread
Stdlib regularity
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: John Prevost <prevost@m...>
Subject: Re: Proposal for study: Add a categorical Initial type to ocaml
skaller <skaller@maxtal.com.au> 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
null.

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
values.

John.