Re: Collective response to := messages

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

From article <10913@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
> Alternatively, suppose ":=" overloadings are required to have an in out-mode 
> parameter to represent the target variable.  Then it would be impossible 
> to assign to an undefined variable, because the variable would first be 
> constraint-checked when it is passed in to the assignment procedure.

    This is a question which applies to any assignment procedure,
    whether ":=" or "ASSIGN".  The way I do it is to use in-out mode
    and implement the ADT as a pointer to a descriptor.  That way,
    I take advantage of the fact that all pointers are automatically
    initialized to null, and I use the null-pointer state as the 
    "empty" or "undefined" state of my ADT.  I'd prefer that all
    data types were automatically initialized to "undefined", so I
    could save the space and time associated with the pointer, but
    the workaround does get the job done.
 
>>    The problems mentioned pertain specifically to this implementation
>>    only; if EVEN were implemented as a limited private type within an
>>    appropriate package, all the operations mentioned would be available 
>>    only through the procedures/functions provided.  Type conversions
>>    would not be legally expressible in the usual notation, most attributes
>>    would not be defined, etc.  Ada 83 allows us to do all of these things,
>>    but not in the "conventional" notation.  
> 
> That's the whole point of why you don't need assignment overloading!!!  
> You can also do assignment with limited private types, but not in the 
> "conventional" notation.  All you need to do is provide an "appropriate 
> subprogram".

    Yes, I've been doing exactly that for a long time now.

>>    Only assignment and destruction play vital roles in the evaluation of
>>    parameters and in the creation and destruction of variables (particularly
>>    with regard to block entry and exit).  It is the fact that the language
>>    does not consider the impact of these mechanisms upon the ADT paradigm,
>>    mechanisms which can play havoc with our abstractions, that compels us 
>>    to call for changes in the language with regard to the ability to
>>    define specific procedures for assignment and destruction which are 
>>    taken into consideration by these mechanisms. 
> 
> We can argue about implicitly invoked destruction mechanisms some other time, 
> since Ada provides no such animal.  And Ada's parameter passing mechanisms 
> are defined implicitly, beyond the reach of the programmer, as they should 
> be (again to enforce type checking)--they have nothing to do with assignment 
> at the source level.  Regarding your assignment "abstraction", all I can 
> offer is the suggestion that reduction to LCD form is an over-specification 
> of what I consider to be the normal semantics of an assignment operation, 
> and it is better left to another procedure [...]

   The LCD example is not mine, and I'll leave it to the author of the
   example to make whatever counterpoints are appropriate.  But with regard
   to the point concerning enforcement of type checking, I'd like to point
   out that the example you gave was one in which you did NOT define an ADT;
   all you did was define a local record type.  I made the suggestion earlier
   that the definition of assignment, comparison, and other operators be
   restricted to the package specification in which the (limited) private 
   ADT type was defined.  The intent was to prohibit the implementation of
   an assignment operator over some limited private type declared somewhere
   else (e.g., TEXT_IO.FILE_TYPE).  Another point: the ADT-handling package
   could leave the denominator as an undefined integer if it jolly well
   felt like it, as long as it met the requirements imposed by the package
   specification.  I don't see how that would constitute any violation of
   type checking.  
   
>>    It is entirely possible that given the desire of AJPO to minimize the
>>    extent of changes in the language, it will not be possible to get Ada
>>    to provide complete support for the abstract data type paradigm.  Ada
>>    was explicitly intended as an interim solution, covering the range
>>    1983..20xx, and not as "the perfect language".  Perhaps for Ada it is
>>    already too late.  But the issue needs to be thoroughly discussed,
>>    because it is a major area in which Ada has "missed the boat". 
> 
> I tend to agree with your last comment.  But Ada's abstraction mechanisms 
> will never be improved in the next revision without a proposal that is 
> carefully thought out and is fully consistent with the goals of the 
> language.  As I've tried to illustrate, none of the proposals I've seen 
> for assignment overloading come close to meeting these criteria.

    I think providing complete support for the abstract data type paradigm
    is fully consistent with the goals of the language; as for carefully
    thought out proposals, a major purpose of this discussion is to uncover
    bugs in the details of the proposal prior to filing the 9X revision
    forms (which were made available by AJPO at Tri-Ada '88).  The points
    that have been made by you and others have done that.  Whether the 
    finalized request will be within AJPO's tolerance for change is,
    of course, still very much an open question.  But in this language
    or the next, the abstraction mechanisms available to programmers
    will be significantly stronger as a result. 


                                       Bill Wolfe

                                wtwolfe@hubcap.clemson.edu