Re: Collective response to := messages

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

From article <10906@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
> One of the nice features of Ada type constraints is
> that they are (or at least were intended to be) implemented consistently
> throughout the language, in part via the basic operations.  This consistent
> enforcement would be lost if overloading of basic operations were allowed.  In
> particular, by allowing overloading of assignment, it would be possible to
> override one of the fundamental steps of the assignment operation, which is to
> guarantee that the target variable in an assignment statement is assigned a
> legal value of its type.  

     Since the overloaded assignment would be implemented in terms of
     the existing low-level assignment operations, I don't see where any 
     potential problem exists here.  Please clarify.
 
> As I understand your LCD example, you seem to see assignment overloading
> as a vehicle for implementing type constraints that can't be expressed in
> Ada's constraint language (such as LCD-ness).  
> [...] 
> Yet after all these exertions, my evenness constraint would STILL not
> be enforced consistently, unless I was given several more language changes.
> For example, type conversions, qualifications, attribute evaluations and
> membership tests never propagate exceptions.  Yet what would be the effect
> of the type conversion "EVEN(3)"?  What would be the effect of the attribute
> evaluation "EVEN'POS(3)"?  What would be the effect of the tests
> "2 in 0 .. 3" or "3 in 0 .. 10" ?  Should they raise CONSTRAINT_ERROR, or
> should they round 3 to some even value?  

    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.  

    Since Ada does not allow implicit type conversions, the fact that we
    cannot overload type conversion does not cause us any grief in the
    parameter-passing process.  Nor do any of the other operations mentioned.

    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. 

> I agree with Geoff.  The proponents of assignment overloading have not
> addressed the ramifications of their proposal thoroughly enough to come
> up with a fully consistent change to the language.  

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

    Perhaps there is a solution which AJPO will find acceptable.  We must
    know whether or not this is the case.  If there is no hope for Ada,
    then we must focus on the construction of Ada's successor.


                                           Bill Wolfe

                                    wtwolfe@hubcap.clemson.edu