Path: utzoo!attcan!uunet!husc6!cmcl2!nrl-cmf!ukma!gatech!ncsuvx!ece-csc!ncrcae!hubcap!billwolf
From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.lang.ada
Subject: Re: Ada Language Change: Assignment Overloading
Message-ID: <3658@hubcap.UUCP>
Date: 24 Nov 88 01:55:31 GMT
References: <8811221935.AA21274@grebyn.com>
Sender: news@hubcap.UUCP
Reply-To: wtwolfe@hubcap.clemson.edu
Lines: 75

From article <8811221935.AA21274@grebyn.com>, by karl@grebyn.com (Karl Nyberg):
> From: mendal@sierra.stanford.edu (Geoff Mendal)
> 
>    Consider the following compilation:
> 
>      with Text_Io;
>      package P is
>        X : Text_Io.File_Mode := Text_Io.In_File;
>      end P;
> 
>    If assignment were to be overloadable, then it would not be allowed
>    to be a basic operation.  Therefore, assignment would not be made
>    directly visible in the above package.  One would need a use clause or
>    a renaming declaration to achieve such direct visibility.  Thus,
>    making assignment an overloadable operation is NOT an upward compatible
>    change.  It would break virtually every program written, it would
>    require changes to the scope and visibility rules, and would require
>    little tweaks to the language such as in the semantics of renaming.

   Why can't an overloadable operation remain as a basic operation?

   In order to preserve compatibility, the "old" interpretation of
   assignment could be kept as the outermost interpretation (deepest
   in the background), available as a default assignment procedure.

>    Program provers might rely on the fact that if no exception is raised 
>    during the "assignment", that the the value is assigned to the object.  
>    This follows Ada's current semantics.  But now through overloading 
>    assignment, we can make that very important assumption no longer true.  
>    Program provers could no longer rely on the semantics of simple 
>    assignment, thus significantly hindering the efforts to prove 
>    anything about a program.  

   And what about the overloadable relational operators???

   Program provers cannot now assume that "=" really means equality,
   nor can they assume that some side effect will not occur during the
   evaluation of an equality operator.  There is plenty of precedent here.
   If we go ahead and overload assignment, the program prover will be able
   to exercise one simple, consistent rule: "Assume nothing".  I think this
   is an excellent mode of thought to force a program prover into.  

>    And yes, what would be the semantics of overloaded assignment for
>    task objects and predefined File_Type objects?  Could it not be
>    the case here that current semantics would be broken through clever
>    use of overloading to assign limited objects?

   The same argument applies in general to the overloadable relational 
   operators; a possible solution would be to require that operators,
   if they are defined over a private or limited private type, must
   be defined within the package specification in which the private
   or limited private type is defined.  This covers File_Type objects;
   since task objects are woven directly into the language rather than
   being included in a predefined package, there isn't even a package
   specification into which an overloadable operator could be inserted. 

> The proponents of overloading assignment have also overlooked other
> less costly solutions such as pre-processors that would transform
> "overloaded assignment" into Ada procedure calls, implementation-defined
> pragmas, etc.  The technology for these kinds of solutions are readily
> available.  If you need such capability, pound on your local Ada
> APSE vendor for the tools.  This is an APSE issue, not a language
> issue, you know.

    Wrong.  The ability to cleanly define abstract data types 
    is very much a language issue.  Implementation-defined pragmas
    would annihilate portability.  Preprocessors would have one hell
    of a time implementing "If this procedure call involves passing
    a user-defined ADT by value, then generate a temporary variable
    of that type, invoke ASSIGN on that temporary (assuming we adhered
    to the convention of using the name ASSIGN rather than, for example,
    COPY or DUPLICATE), and pass the temporary instead, and remember 
    to invoke DESTROY on the temporary afterward"...

    There's no way around it.  Assignment needs to be overloadable.