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