Overloading of assignment

Overloading of assignment

[Mats Weber]

The question of what an overloaed assignment procedure should look like still
remains:

  variant A:

  procedure ":=" (OBJECT : out SOME_LIMITED_TYPE;
                  VALUE  : in  SOME_LIMITED_TYPE);

  variant B:

  procedure ":=" (OBJECT : in out SOME_LIMITED_TYPE;
                  VALUE  : in     SOME_LIMITED_TYPE);

The problem with variant A is that if SOME_LIMITED_TYPE has subcomponents that
are of an access type, then no garbage collection can be performed on OBJECT
before assigning it its new value, because OBJECT cannot be read inside ":=".

The problem with variant B is that it cannot be used for the initialization
of an object (unless SOME_LIMITED_TYPE is an array or record type) because the
actual parameter for OBJECT must have a defined value before the use of ":="
(otherwise the program is erroneous). Consider the following example:

   package ADT is

      type T is limited private;

      procedure ":=" (OBJECT : in out T; VALUE : in T);

      function TO_T (N : INTEGER) return T;

   private

      type T is range 0..1000;

   end ADT;

   with ADT;
   procedure P is

      X : ADT.T;

      use ADT;

   begin
      X := TO_T(7);    -- this call of ":=" is erroneous because X
   end P;              -- is undefined.


Variant A is better if SOME_LIMITED_TYPE is a scalar type,
variant B is better if SOME_LIMITED_TYPE is an array or record type,
both variants work with access types as these always have the initial value
null.

Personally, I think the rules on assignment in Ada cannot be changed if
upward compatibility is to be acheived.

Mats Weber
DI-LITh-EPFL
Swiss Federal Institute of Technology
1015 Lausanne
Switzerland

e-mail : madmats@elma.epfl.ch

Re: Overloading of assignment

[William Thomas Wolfe,2847,]

From article <881125130910.218003ab@elcc.epfl.ch>, by madmats@elma.epfl.ch (Mats Weber):
! Consider the following example:
! 
#    package ADT is
#       type T is limited private;
#       procedure ":=" (OBJECT : in out T; VALUE : in T);
$       function TO_T (N : INTEGER) return T;
$    private
$       type T is range 0..1000;
%    end ADT;
% 
%    with ADT; use ADT;
&    procedure P is
&       X : ADT.T;
*    begin
*       X := TO_T(7);    -- this call of ":=" is erroneous because X
*    end P;              -- is undefined.

 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.

 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.

Re: Overloading of assignment

[William Thomas Wolfe,2847,]

From article <3667@hubcap.UUCP>, by billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,):
#  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.
                                                    31         31
   Technical corrections: the new range would be -(2  - 1) .. 2  - 1,
                          and -1 * MIN_INT would no longer raise
                          NUMERIC_ERROR (or CONSTRAINT_ERROR or whatever).

Re: Overloading of assignment

[Stephe Leake]

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