* Assignment Overloading
@ 1988-12-06 13:05 TUFFS1
1988-12-14 18:05 ` William Thomas Wolfe,2847,
0 siblings, 1 reply; 2+ messages in thread
From: TUFFS1 @ 1988-12-06 13:05 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Assignment Overloading
1988-12-06 13:05 Assignment Overloading TUFFS1
@ 1988-12-14 18:05 ` William Thomas Wolfe,2847,
0 siblings, 0 replies; 2+ messages in thread
From: William Thomas Wolfe,2847, @ 1988-12-14 18:05 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1988-12-14 18:05 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1988-12-06 13:05 Assignment Overloading TUFFS1
1988-12-14 18:05 ` William Thomas Wolfe,2847,
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox