Re: Ada Language Change: Assignment Overloading

[billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)]

From article <8811221935.AA21274@grebyn.com>, by karl@grebyn.com (Karl Nyberg):
> From: mendal@sierra.stanford.edu (Geoff Mendal)
> 
> 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.

   First, assignment is a "fundamental" operation; except for attributes,
   the other things you've suggested apply only to specific classes of
   ADTs.  As for attributes, I think we could live without them if 
   appropriate procedures and functions were defined over the predefined
   ADTs; having attributes for predefined ADTs and functions for user-defined
   ADTs is another inconsistency.  Procedures and functions are definitely
   necessary; the attribute mechanism is not.

   Now another aspect of this problem is the principle that users should
   be able to define ADTs which are just as powerful as the predefined
   ADTs; obviously, this is not presently the case with Ada.  With regard
   to attributes, I think elimination of the feature will bring Ada into
   compliance with this principle, and result in general simplification.

   Another reason is that assignment procedures need to be invoked as part
   of the evaluation of a user-defined ADT which is passed by value.  No
   similarly vital function is performed by the other operations suggested.

   The argument that the operations listed (except assignment and attributes)
   should be user-programmable with respect to user-defined ADTs is reasonable,
   but clearly assignment is in a higher class of importance than the others.

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

   procedure ":=" (FIRST_OBJECT  : in out TYPE;
                   SECOND_OBJECT : in     TYPE);

   would seem appropriate.