Re: To Initialise or not

[kst@thomsoft.com (Keith Thompson)]

In <Dqq7qB.LFn@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
[...]
> Why restrict it to access values?  As I said in another post, an integer
> array index is a pointer, just like an access value, and allowing
> totally undefined array index values can do just as much damage as
> allowing undefined access values.

Because it's much more straightforward for access types (and for
floating-point types: NaN, Infinity, etc.) than for integer types.
It's easy to reserve as many special access values as you need.  Users --
and hardware -- tend to expect each possible bit-pattern of an integer
object to represent a valid integer value.  You could reserve the most
negative integer in a two's-complement representation, but that gets
complicated in the absence of hardware support.

> While we're talking about language design: I think the idea of always
> having a single "special" value, and always calling it "null" is ugly.
> Some access types shouldn't *have* a null value at all.  (E.g. consider
> a circular linked list, with a dummy header element.  The links can
> *never* be null, unless there's a bug.)  And when I *do* need an extra
> "special" value, why is it always called "null"?  In one case, it ought
> to be called "End_Of_List".  In another case it should be called
> "Not_Yet_Determined" or something.  And why can't I have *two* of the
> special things?

It isn't always called "null":

    End_Of_List: constant My_Access_Type := null;

If you want more than one special value, here's one way you might do it:

    End_Of_List           : constant My_Access_Type := null;
    Not_Yet_Determined    : constant My_Access_Type := new My_Object_Type;
    Insufficient_Caffeine : constant My_Access_Type := new My_Object_Type;

Of course, the compiler won't enforce your intention not to refer to
the designated objects.

If you happen to know how your compiler implements access types, you can
initialize the special constants with illegal pointer values, and hide
the details inside a private part or package body.  Hopefully attempts
to dereference these values will cause something bad to happen, ideally
an exception.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
This sig uses the word "Exon" in violation of the Communications Decency Act.