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,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!cme-durer!leake
From: leake@cme-durer.ARPA (Stephe Leake)
Newsgroups: comp.lang.ada
Subject: Re: Ada Language Change: Assignment Overloading
Message-ID: <743@marvin.cme-durer.ARPA>
Date: 23 Nov 88 12:36:32 GMT
References: <8811221935.AA21274@grebyn.com>
Organization: National Bureau of Standards, Gaithersburg, MD
In-reply-to: karl@grebyn.com's message of 22 Nov 88 19:35:15 GMT
List-Id: <comp.lang.ada>


Thanks to Geoff Mendal for giving a careful, reasoned response to the
suggestion of allowing overloading of ":=". I would like to respond to
a couple of his points:

	1. Why simply restrict it to assignment? ...

Good point; we need to consider each in turn, something I assume the
original language design team did. Where can I get the documentation
on their decisions?

	2. Why is an overloading of assignment needed? ...

I stand guilty of sloppy thinking: I have accused others of not giving
specific examples of what changes would gain, and now I have none.

	3. Overloading assignment will break virtually all Ada programs. ...

A very good point!

	4. Finally, what would an overloading of assignment look like? ...
	   (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.

The assignment is ambiguous because the second function F is not a
"pure" assignment; it is also a type conversion. All overloading is
subject to this type of abuse; the fact that it is also possible in
overloading assignment is not significant. In fact, carefull use of
this possibility could lead to more readable programs, by eliminating
lots of explicit type conversions (although my first reaction is that
the program should be restructured: explicit type conversions are
usually an indication that something is fundamentally wrong).

     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;

Yes, it is erroneous. But again, the problem is the idiotic definition
of ":="; the same idiotic definition could be given for "*", with
equally erroneous results. This is not unique to ":=". (Note that the
DEC compiler will issue a warning on compiling ":=", since the out
parameter is never given a value).

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

If we consider expressions results passed as actual parameters, the
same problem arrises with idiotic definitions of "*". I agree that
":=" seems more of a problem, but it is still not unique.

   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?

These cannot be overloaded, since they are declared limited private in
packages that we cannot modify; just like other operators, assignment
for a limited private type should only be declarable in the same
declaration region the type is declared in.

	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.

These are definitely inferior solutions; if you want pre-processors,
use C! :-)

On the whole, I think the arguments in 2 and 3 are sufficient. I
hereby withdraw my request for overloading ":=". And thanks again for
the time spent.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899