Message-Id: <199910092226.PAA02183@fiji01.liquidmarket.com>
To: skaller <skaller@maxtal.com.au>
Subject: Re: Stdlib regularity
In-Reply-To: Your message of "Sat, 09 Oct 1999 00:56:26 +1000."
<37FE061A.7DA264A2@maxtal.com.au>
Date: Sat, 09 Oct 1999 15:26:02 -0700
From: Francois Rouaix <frouaix@mail.liquidmarket.com>
<skaller@maxtal.com.au> writes:
skaller> There are several cases where the core language prevents
skaller> this, because it lacks functionality available in C++: the
skaller> ability to create uninitialised values, and the ability to
skaller> destroy them are two that I've become aware of trying to build
skaller> a variable length array module.
Uninitialized values are easily implemented with the 'a option type.
Of course, the code is then ugly, because you have to match your
values everywhere to None | Some x. In C/C++ terms, this forces you
to check for NULL pointers systematically, which is a Really Good Thing.
Adding uninitialised values is a major source of bugs, and it's kind
of natural to pay the price for it in the readability of the source,
if you want your code to be robust.
skaller> [About a functor for an extensible array type, and the problem
skaller> of a dummy value]
Builtin arrays require you to provide a initialization value, even for
zero-length array. Why don't you carry the same requirement to your
extensible arrays, and simply use a polymorphic type:
type 'a earray = {
mutable current : 'a array;
mutable used : int;
}
let create n i = { current = Array.create n i; used = n }
And then, if you want to have the equivalent of NULL pointers, use None,
and option types everywhere.
It seems to me that you are trying to force the language to do something
it has been purposely designed against. I'm not sure you can win this fight.
--f
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:26 MET