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: <10913@ulysses.homer.nj.att.com> Date: 30 Nov 88 22:28:37 GMT References: <10906@ulysses.homer.nj.att.com> <3698@hubcap.UUCP> 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 <3698@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes: >>From article <10906@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum): >> 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. Essentially, the problems arise from the characteristics of Ada's parameter passing semantics. (Or we could change those too while we're at it. :-) ) Suppose ":=" overloadings are required to have an out-mode parameter to represent the target variable. Then an overloaded ":=" on a composite type can selectively assign to some components of the target and leave other components undefined (if they were undefined prior to execution of the assignment). This cannot happen with predefined assignment to objects of a composite type (i.e., when a full composite object, not just a component of one, is given as the left-hand side). 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. For example, procedure CIRCUMVENT is type LCD_FORM is record NUMERATOR, DENOMINATOR : INTEGER; end record; X, Y : LCD_FORM; -- X and Y undefined. procedure ":=" (L : out LCD_FORM; R : in FLOAT) is begin if R = 0.0 then L.NUMERATOR := 0; else -- calculate LCD form. end if; end ":="; begin X := 1.5; -- X.NUMERATOR is presumably 3, X.DENOMINATOR is presumably 2. -- Y.DENOMINATOR is undefined. Y := 0.0; -- Y.DENOMINATOR is STILL undefined. end CIRCUMVENT; You can object that I didn't define ":=" "correctly" and that I stupidly failed to assign to DENOMINATOR when R is zero, but that's the whole point--I've circumvented the type checking that is inherent in predefined assignment. > >> 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. 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". > > 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. You seem to be missing my point. You are trying to use an overloaded assignment operator to implement a constraint on your LCD type that can't be expressed in Ada's constraint language. I've argued that I would want the ability to overload the other basic operations so that I could implement in a consistent manner the constraints that I may dream up. You've ignored that argument and instead still seem to be harboring the belief that assignment is "different" from the other basic operations. What is so unique about assignment that it alone of all the basic operations requires special treatment? > > 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 whose sole purpose is to perform the reduction. If you define your LCD type as a limited type in a package, you can provide a NORMALIZE procedure which will achieve the desired effect. If you need to add new code later, your only recourse will be to use the NORMALIZE procedure, as there is no predefined assignment operation available to confuse you. > 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. ------------------------------------------------------------------- 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 -------------------------------------------------------------------