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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!ucbvax!grebyn.com!karl
From: karl@grebyn.com (Karl Nyberg)
Newsgroups: comp.lang.ada
Subject: Ada Language Change: Assignment Overloading
Message-ID: <8811221935.AA21274@grebyn.com>
Date: 22 Nov 88 19:35:15 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Grebyn Corporation
List-Id: <comp.lang.ada>

[Ed. - this seems to have fallen through the cracks somewhere...]

-- Karl --

From: mendal@sierra.stanford.edu (Geoff Mendal)

I am surprised that no one has yet challenged the proposal to make
assignment an overloadable operation in the next revision of Ada.
There are many problems I have with this idea, which I feel compelled
to enumerate.  Most of these problems have been articulated by myself
and others before, but here goes.

1. Why simply restrict it to assignment?  Why not include membership,
   short-circuit control forms, indexing, selection, attributes, etc.?
   These are all basic operations.  I can think of many applications
   for overloading membership instead of having to write a function.
   Likewise, I can think of applications where an overloading of indexing
   would make my code more readable.  How I would love to be able to
   define my own attributes and use the attribute notation.  The point
   is that there is nothing special about assignment.  Therefore, it
   seems to me short-sighted to exclude other basic operations from the
   overloading status discussion.

   (Doug Bryan calls this the "infinity argument" so labeled because
   your ten changes, my ten changes, and so on add up to an infinite
   amount of changes that most likely make the situation worse, not
   better.)

2. Why is an overloading of assignment needed?  To avoid having to
   type an Assign procedure call?  This is silly.  While some readability
   may be gained by having assignment overloadable, program understandability
   dimishes.  This is one reason why there are so many restrictions on
   user-defined equality.  Increasing readability at the expense of
   understandability is not a good tradeoff.  Whining that typing a
   six character "Assign" procedure call makes a program too unreadable
   is poppy-cock.  Would you want to trust an overloading of ANYTHING
   to those programmers who are too lazy to type six character identifiers?
   Besides, coding is 10% of the software lifecycle.  Typing may account
   for 1% of that 10%.  Any language change whose sole benefit is to
   increase the productivity of 0.1% of the software lifecycle (at the
   possible expense of the remaining 99.9%) is highly suspect.

   It seems to me that when programmers say they want assignment overloaded,
   it is so that they can do much more than a simple assignment in the
   overloaded subprogram.  This would greatly reduce program understandability.
   In such cases, an Assign procedure is the right language construct to
   use.

3. Overloading assignment will break virtually all Ada programs.  We all
   know that operators which are not directly visible can be made so by a
   use clause (with some potential problems which I won't delve into) or
   a renaming declaration.  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.

   These are the types of problems we don't need for the next revision of
   Ada.  I would like the proponents of assignment overloading to consider
   these issues before they jump on the bandwagon proclaiming a wonderful
   change to the language.

4. Finally, what would an overloading of assignment look like?  Would
   one parameter have to be mode in and the other mode out?  What about
   mode in out?  What about side effects?  Would it be a function or
   a procedure, or both?  What about overload resolution changes
   (consider the following program, is the "assignment" ambiguous)?

     procedure Main is
       type Int is new Integer;
       type A1 is access Integer;
       type A2 is access Int;

       function F return A1 is begin ... end;
       function F return A2 is begin ... end;
       procedure ":=" (L : out Integer; R : in Integer) is
       begin
         ...
       end;
       procedure ":=" (L : out Int; R : in Integer) is
       begin
         ...
       end;
     begin
       F.all := Integer'First;  -- ambiguous?
     end Main;

   Note that the above program would be legal if the two ":=" procedure
   bodies were removed.

   Next, consider the following example:

     procedure Erroneous is
       X : Integer;
       procedure ":=" (L : out Integer; R : in Integer) is
       begin
         null;
       end;
     begin
       X := Integer'First;
       -- Does reference to X's value here make the execution of the
       -- program erroneous?
     end;

   In the above example, we run into a serious problem.  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.  Currently, if an assignment operation proceeds without
   exception, then it must be the case that the variable name is assigned
   the value specified (with some exceptions regarding assigning an
   uninitialized object to another).

   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 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.

In summary, there are many areas of the language that need attention.
Overloading assignment may sound like a great idea on the surface but
the problems exposed by any tampering with the current semantics outweigh
any readability benefit that might be gained.

You may now shoot me with arrows.  I don't care... I'm on holiday.

gom