From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!ulysses!hector!dsr From: dsr@hector.UUCP (David S. Rosenblum) Newsgroups: comp.lang.ada Subject: Re: Collective response to := messages Message-ID: <10906@ulysses.homer.nj.att.com> Date: 30 Nov 88 16:29:23 GMT References: <8811282217.AA04896@ajpo.sei.cmu.edu> <24856@sri-unix.SRI.COM> Sender: netnews@ulysses.homer.nj.att.com Reply-To: dsr@hector.UUCP (David S. Rosenblum) Organization: AT&T Bell Laboratories, Murray Hill, NJ List-Id: 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 -------------------------------------------------------------------