Re: Collective response to := messages

[dsr@hector.UUCP (David S. Rosenblum)]

In article <24856@sri-unix.SRI.COM> trent@unix.sri.com (Ray Trent) writes:
>In an article mendal@ANNA.STANFORD.EDU (Geoff Mendal) writes:
>>
>>First, assignment is NOT an operator.  It is a basic operation.
>
>The argument is that it should be. (and is, in any sensible 
>(i.e. non-Ada) definition of the word operator) That there is no
>reason to have "basic" operators that are "special".

Most of the non-Ada definitions of "operator" that I am familiar with
describe operators in a purely mathematical sense, i.e. in terms of
domains and algebras.  However, assignment is a concept that is peculiar to
programming languages, so in a sense you're comparing apples and oranges.
And most "sensible" definitions of assignment that I know of describe
assignment simply in terms of placing a value in a variable or memory location.

Basic operations in Ada ARE special, for very good reasons.  Unlike operators,
they are intimately connected with Ada's model of type constraints in some
way and cannot be hidden.  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.  When you overload operators such as "=" and "+",
you may give perverse semantics to operators that have a "traditional"
meaning, but you are not able to override Ada's type checking.  Thus,
allowing overloading of assignment (or any basic operation) would seriously
weaken Ada's strong typing features.

>[lots of discussion about LCD deleted]

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).  So why stop with assignment?
Wouldn't you need overloading of all the basic operations?  Suppose
I'm given a language change which allows overloading of basic operations,
and suppose I have a type EVEN, e.g.,

	type EVEN is new INTEGER;

which I want to constrain in a way that would require all variables of
the type to have even values.  In order to enforce this constraint
consistently in the manner of Ada, I would want to do the following:

(1) Overload := so that it raises CONSTRAINT_ERROR when given an odd
    right-hand-side.
(2) Overload the attributes 'SUCC and 'PRED so that they skip odd values.
(3) Overload the attributes 'POS and 'VAL so that count only even values.
(4) Overload the attribute 'FIRST so that it returns the smallest even
    value of EVEN's base type.
(5) Overload the attribute 'LAST so that it returns the largest even
    value of EVEN's base type.
(6) Overload the membership tests and the ".." token so that only
    even ranges are considered.
(7) Overload the indexing operation for all array types I define that are
    indexed by EVEN values, so that even-numbered components are stored and
    accessed contiguously.
(8) Overload the aggregate operation for such array types so that
    the index values for the aggregate are computed "the right way".

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?  Suppose I instantiate INTEGER_IO to
perform I/O on EVEN values.  How do I get the instantiation to enforce my
evenness constraint?  First I would need another language change that requires
source-level assignment "operators" to be used to implement parameter
passing.  But I'm still in trouble because my overloaded := cannot be made
visible to my INTEGER_IO instantiation.  So I would ALSO need INTEGER_IO to be
redefined to accept a generic formal := parameter.  Oy!

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.  Until they do, I'm
happy to write ASSIGN instead of := whenever I need a "special" assignement
operation.


-- David

-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------