Overloading of ":="

Overloading of ":="

[Mats Weber]

In his message dated 3 Dec 88 21:08:16 GMT, mcvax!enea!sommar@uunet.uu.net
(Erland Sommarskog) writes:

>   Generic
>      Type Data_type is limited private;
>      With procedure Assign(A : in out Data_type;
>                            B : in     Data_type);
>      With function "<"(A, B : Data_type) return boolean is <>;
>      With function ">"(A, B : Data_type) return boolean is <>;
>   Package Binary_trees is
>
>With an overloadable ":=" I could have declared the second parameter as
>
>      With procedure ":="(A : in out Data_type;
>                          B : in     Data_type) is <>;
>
>This would save the user from declaring unnecessary Assign for types like
>integer. This Assign procedure he has to write is simple, but is 100% noise
>to his code.

Instanciating and using this generic package with Standard.Integer (or any
type that does not have a default initial value) is ERRONEOUS because the
formal parameter A of Assign or ":=" is of mode 'in out', hence the
corresponding actual paramter must be an initialized variable.

For more information on this subject, read the paper by Genillard et al.
"Rationale for the Design of Reusable Abstract Data Types Implemented in Ada"
To appear soon in Ada Letters.

Another document that should be read by anyone before even thinking of Ada 9x
language changes is "Rationale for the Design of the Ada Programming Language"
by Ichbiah et al.

Mats Weber
Swiss Federal Institute of Technology
EPFL DI LITh
1015 Lausanne
Switzerland

e-mail : madmats@elma.epfl.ch

Re: Overloading of ":="

[Erland Sommarskog]

Mats Weber (madmats@elma.epfl.ch) writes:
 >I said:
 >>   Generic
 >>      Type Data_type is limited private;
 >>      With procedure Assign(A : in out Data_type; B : in  Data_type);
 >>      With function ">"(A, B : Data_type) return boolean is <>;
 >>      With function "<"(A, B : Data_type) return boolean is <>;
 >>   Package Binary_trees is
 >>
 >>With an overloadable ":=" I could have declared the second parameter as
 >>
 >>      With procedure ":="(A : in out Data_type; B : in Data_type) is <>;
 >>
 >Instanciating and using this generic package with Standard.Integer (or any
 >type that does not have a default initial value) is ERRONEOUS because the
 >formal parameter A of Assign or ":=" is of mode 'in out', hence the
 >corresponding actual paramter must be an initialized variable.

This is of course erroneous no matter if we call the procedure Assign
or ":=". The interesting point is of course if the erroneousity
here is really crucial. As long as we don't actually read A, it
doesn't really matter. So for standard.integer there is no problem.
But for types with range constraints there could appear an unexpected
and unnecessary constraint_error. However, we can easily circumvent
this with a surpress pragma for our Assign procedure. 
  Now, WHY, is A of mode "in out" in the Assign procedure? If we had
"out" only, nothing "erroneous" could occur. And, any user who wanted
to store a limited type in a tree would get no help from us. (The 
Text type from Text_handler in the LRM is a perfect victim.) 
-- 
Erland Sommarskog
ENEA Data, Stockholm              This signature is not to be quoted.
sommar@enea.se

Re: Overloading of ":="

[William Thomas Wolfe,2847,]

From article <4189@enea.se>, by sommar@enea.se (Erland Sommarskog):
> [Mats Weber and Erland Sommarskog rehash the argument about
>   assignment procedures having an "in out" parameter for the destination] 
> 
>   Now, WHY, is A of mode "in out" in the Assign procedure? If we had
> "out" only, nothing "erroneous" could occur. 

     Because the ASSIGN procedure needs to be able to DESTROY the old
     value; DESTROY procedures must read objects during the process
     of destroying them.  Please review the recent discussion rather
     than recreating it, unless there are new issues to be considered.

Re: Overloading of ":="

[Erland Sommarskog]

Bill Wolfe (billwolf@hubcap.clemson.edu) writes:
>From article <4189@enea.se>, by sommar@enea.se (Erland Sommarskog):
>> [Mats Weber and Erland Sommarskog rehash the argument about
>>   assignment procedures having an "in out" parameter for the destination] 
>> 
>>   Now, WHY, is A of mode "in out" in the Assign procedure? If we had
>> "out" only, nothing "erroneous" could occur. 
>
>     Because the ASSIGN procedure needs to be able to DESTROY the old
>     value; DESTROY procedures must read objects during the process
>     of destroying them.  Please review the recent discussion rather
>     than recreating it, unless there are new issues to be considered.

Talk about rehash. We all know, except Bill of course, that the memory-
management problem is best handled with garbage collection.

As for the answer to the question above, the answer is simply that
   Generic
      Data_type is limited private;
      With  procedure Assign(A : out Data_type; B : in Data_type);
   Package...
is illegal. Parameters of a limited type may not be in "out" mode.
  This means, as Mats pointed out, that to use this package for 
type without a default value, like standard.integer, the user have to  
do something erroneous. I, in my turn, pointed out that this was not
a problem in practice except for constrained types, and that this
case also easily was handled with a "supress" pragma.

Please read more carefully before you flame. We didn't talk about
memory management. We didn't even talk about access types.-- 
Erland Sommarskog
ENEA Data, Stockholm              This signature is not to be quoted.
sommar@enea.se

Re: Overloading of ":=", ADT survivability

[William Thomas Wolfe,2847,]

From article <4193@enea.se>, by sommar@enea.se (Erland Sommarskog):
>>>   Now, WHY, is A of mode "in out" in the Assign procedure? If we had
>>> "out" only, nothing "erroneous" could occur. 
>>
>>     Because the ASSIGN procedure needs to be able to DESTROY the old
>>     value; DESTROY procedures must read objects during the process
>>     of destroying them.  Please review the recent discussion rather
>>     than recreating it, unless there are new issues to be considered.
> 
> Talk about rehash. We all know, except Bill of course, that the memory-
> management problem is best handled with garbage collection.

And in article <4195@enea.se>, Erland also writes:
> I think Ada should require garbage collection
> that could be disabled with a pragma for critical applications.

    But consider what happens when the programmer of a critical
    application must write his/her assignment procedures.  Use
    of the "out" mode results in the production of garbage.  Since
    the GC crutch is not available, the more survivable "in out"
    mode is then preferred.  

    Now since we know that "out" mode is worthless under certain
    circumstances, and since ADT designers must design for the widest
    possible audience, "in out" is the mode of choice.

    Similarly, when performing deletions and such, ADT designers must
    again design for the widest possible audience.  This directly implies
    an ADT which manages its own deallocations.  

    Certain aspects of the language tend to interfere with the need 
    of critical applications to exercise total control over memory 
    management; among these are the inability to integrate DESTROY
    procedures into the automatic destruction of local environments.

    Sure, it requires more mental discipline to be space-conscious.
    But with experience, it becomes automatic.  Forgive me if I've
    been a bit harsh at times, but once a person has become accustomed
    to managing space and time simultaneously, complaints regarding
    pointer errors sound very much like complaints that it's too
    difficult to have to walk and chew gum at the same time. 

    I like to program my ADTs to be *survivable*, in the hardest possible
    sense.  An ADT should be capable of surviving multitasking, invalid 
    parameters, memory exhaustion, whatever.  Only then will the part
    achieve widespread acceptance.


                                       Bill Wolfe

                               wtwolfe@hubcap.clemson.edu