Path: utzoo!attcan!uunet!cme-durer!leake
From: leake@cme-durer.ARPA (Stephe Leake)
Newsgroups: comp.lang.ada
Subject: Re: Overloading of assignment
Message-ID: <750@marvin.cme-durer.ARPA>
Date: 29 Nov 88 16:01:04 GMT
References: <881125130910.218003ab@elcc.epfl.ch> <3667@hubcap.UUCP>
Organization: National Bureau of Standards, Gaithersburg, MD
Lines: 39
In-reply-to: billwolf@hubcap.clemson.edu's message of 26 Nov 88 19:59:37 GMT

In article <3667@hubcap.UUCP> billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes:

>    The solution is to enable any type of object to be automatically initialized;
>    any type of object should be able to carry the value "undefined", which is
>    automatically assumed by all objects not otherwise initialized.  
>
>    The value "null" would be an alias for "undefined", to preserve compatibility.

But "null" for access types is _not_ the same as "undefined"! I often
use "null" to terminate a list; I do not want all that code to
suddenly be declared erroneous!

>    In the case of integers, for example, we typically have the range
>       31    31                            31        31
>     -2  .. 2  - 1; this would shrink to -2  - 1 .. 2  - 1, using the
>			 31
>    liberated value of -2  as our representation of "undefined", and
>    rendering the range of an integer symmetrical, thus eliminating
>    the problem of having -1 * MAXINT raise a NUMERIC_ERROR.

This is a neat idea; similar to NAN's (Not A Number) in IEEE floating
point. Unfortunately, it is not supported by any hardware I know of.

For enumeration types, the compiler can simply add one more for
undefined; but this might violate a representation clause (for
instance, if I define a type CHAR8 to have 256 elements, represented
in 8 bits, adding an "undefined" would require more bits).

I think, to be truly general, representing "undefined" would force a
record representation for all types, with a discriminant labeling the
object as defined or not. This would be far too much overhead.

I think the origninal Ada concept of an erroneous program is more practical.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899