[comp.lang.ada] Assignment Overloading

TUFFS1@alcoa.com (12/06/88)

I have an observation regarding the overloading of assignment.  A
basic justification seems to be that when building/using an abstract 
data type it becomes tedious to expand functional structures into 
procedural structures.  I agree.  For example:

  X := Y + Z;     versus:  Add(Y, Z, X); 
  X := A + B + C; versus:  Add(A, B, Temp); Add(Temp, C, X); ... etc.

Pre-processing is one solution, but as noted in previous comments, the 
final code is often what matters, and it's ugly. 

To add fuel to the discussion, consider the following code fragment (as 
might occur in a reusable matrix manipulation package):

  type Vectors(Dimension: Positive) is private;
  ...
  function "+"(Left, Right: in Vectors) return Vectors;
  ...
  X, Y, Z: Vectors(3);  
  ...
  X := Y + Z; -- Assuming Y and Z are initialized somewhere above

The problems start when we choose an access type as the private 
representation of Vectors:

  ...
  private
    type Aggregates is array(Positive range <>) of Numbers;
    type Aggregate_Pointers is access Aggregates;
    type Vectors(Dimension: Positive) is record
      Elements: Aggregate_Pointers;
    end record;
    ...

We might do this in order to get pass-by-reference semantics and speed 
up the code. The problem is, what can we do about the storage which may 
already be allocated to X, which will have become unavailable due to the 
implementation of "+":

  function "+"(Left, Right: Vectors) return Vectors is
    Result: Vectors(Left.Dimension) := (Dimension => Left.Dimension,
      Elements => new Aggregates(1 .. Left.Dimension));
  begin
    for Index in 1 .. Left.Dimension loop
       Result.Elements(Index) := Left.Elements(Index) + 
         Right.Elements(Index);
    end loop;
    return Result; -- At this point, previous storage allocated
                   -- to the result object becomes inaccessible.
  end "+";

If your Ada run-time system happens to support automatic garbage 
collection, then fine.  Otherwise, get ready for Storage_Error soner or 
later!  Let's suppose we want to use in-place computation to save space 
and speed.  Let's try:

  X := X + Y;

Unfortunately, this does not give in-place computation, since after the 
assignment X will be "pointing" to a whole new structure, and the 
previous structure will be inaccessible.  What we seem to need is a way 
of "getting at" the thing which is the function result.  

The cure mignt be something along the lines of a new attribute 'Result, 
which would apply to a function, and act like an "in out" procedural 
parameter:

  function "+"(Left, Right: in Vectors) return Vectors is
  begin
    ...
    for Index in 1 .. Left.Dimension loop
      "+"'Result.Elements(Index) := Left.Elements(Index) + 
        Right.Elements(Index);
    end loop;
  end;

This would cure the problems of non-deallocation of space, and allow 
in-place computation to take place.  Also, it does not mess with the 
":=" operator.  However, what do we "return"?  Also, what is the 
'Result in cascaded operations such as X := A + B + C; ?

Alternatively, the language rules could be re-defined to allow 
operator names to be procedures with a single "out" or "in out" 
procedure.

  procedure "+"(Left, Right: in Vectors; Result: in out Vectors);

giving equivalently:

  "+"(Left => A, Right => B, Result => X);
  X := A + B;

and we could do away with the reserved word "function" completely.

Comments, flames, problems?

Simon Tuffs
Tuffs@Alcoa.Com

billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) (12/15/88)

From article <8812140455.AA16282@ajpo.sei.cmu.edu>, by TUFFS1@alcoa.com:
>   X := X + Y;    [-- generates an inaccessible temporary result...]
> 
> Unfortunately, this does not give in-place computation, since after the 
> assignment X will be "pointing" to a whole new structure, and the 
> previous structure will be inaccessible.  What we seem to need is a way 
> of "getting at" the thing which is the function result.  [...] 
>
> Comments, flames, problems?
> 
> Simon Tuffs
> Tuffs@Alcoa.Com

    I've thought about this problem too.  Probably the best way to
    handle it would be to define the parameter passing mechanism
    such that a function result ("anonymous", and thus not referencable
    elsewhere) will always be directly substituted for an "in" parameter,
    rather than being assigned or copied.

    Another idea I had along these lines is the more general question of
    "How can we handle the situation in which a temporary object whose
    sole purpose is to be passed once as an "in" parameter must be 
    1) needlessly assigned or copied during the parameter pass, and 
    2) explicitly destroyed afterward?".  The answer I came up with,
    which I don't recall ever seeing discussed in the literature, is
    "pass by handoff".  In a pass by handoff, you precede the expression
    to be handed off by a @, thus:

           PROCEDURE_CALL (@TEMPORARY_VARIABLE);

    Now what happens is that the object is directly substituted for the
    formal "in" parameter, and the temporary variable is left undefined.

    The problem is that the mechanism requires that all objects have
    "undefined" as a member of their carrier space, and my earlier
    suggestion that all objects should have "undefined" as an implicit
    member of their carrier space did not generate much enthusiasm.
   
    By the way, thanks for the idea of the Deallocate service!


                                        Bill Wolfe

                                wtwolfe@hubcap.clemson.edu