From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!gatech!hubcap!billwolf
From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.lang.ada
Subject: Re: Assignment Overloading
Message-ID: <3890@hubcap.UUCP>
Date: 14 Dec 88 18:05:29 GMT
References: <8812140455.AA16282@ajpo.sei.cmu.edu>
Sender: news@hubcap.UUCP
Reply-To: wtwolfe@hubcap.clemson.edu
List-Id: <comp.lang.ada>

>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