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!pacbell!ames!mailrus!ukma!husc6!sri-unix!trent From: trent@unix.SRI.COM (Ray Trent) Newsgroups: comp.lang.ada Subject: Re: Collective response to := messages Message-ID: <24856@sri-unix.SRI.COM> Date: 29 Nov 88 21:08:27 GMT References: <8811282217.AA04896@ajpo.sei.cmu.edu> Reply-To: trent@unix.sri.com (Ray Trent) Organization: SRI, Menlo Park, CA. List-Id: In an article mendal@ANNA.STANFORD.EDU (Geoff Mendal) writes: >>The Ada apolgists would have us write the semantics for ensuring >>LCD form for the type Fraction into *each and every operator* >>that acts upon 2 items of this type, instead of having that > >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". >One of the examples that I deleted above was "A := B / C;" >where A, B, and C were of some ADT (Fraction). If I understand the >argument for placing the semantics in assignment instead of having the >programmer define the semantics in each user-defined operation, then >how would the semantics of passing the expression "B / C" to some >subprogram formal be handled? There is no "assignment" here. The Fine, perhaps a better example is assigning to an object that should be garbage-collected before assignment. (always, or the program will be erroneous (not in the Ada sense)) Which makes more sense, putting garbage collection in assignment, or assuming the programmer will always call a garbage collector while assigning? Even if the programmer is a code maintainer, and not the designer? If you are wondering why I chose my original example, consider A := (B / C * D) + ... + (Q / (3/4)). (all variables are of type fraction, and an appropriate "/"(A,B : INTEGER) is defined) Do you still want LCD maintainance in the arithmetic operations? Of course, you could always force A := LCD(foo). What if someone wants to modify the program? Aren't they going to wonder/forget about this? If you are worried about passing the expression B / C as a parameter, my answer is: if you have a procedure where LCDness is necessary for proving something, you can *always* simply make "in" parameters "in out" parameters. This *ensures* that an input variable will be in LCD form. (if assignment is overloadable and is overloaded as suggested) "Requiring" a A := LCD(B/C) does not ensure the validity of something passed to a sub-program. If assignment were overloadable, the writer of an Ada spec for operations involving fractions could be *sure* of always having something in LCD form when passed to a subprogram by overloading ":=" and passing all variables as "in out" parameters. The only other way to do this is force *all* subprograms to perform LCDing on their outputs (or inputs) whether that condition is necessary or not. This would make the operation A := extremely slow (potentially). The LRM explicitly says that intermediate results need not follow the constraints of the ADT. >being that Ada is more readable/understandable/etc. than assembly. So >why is it that defining a mapping from some pre-processor to Ada is >met with such cynicism? It simply provides an additional layer of Because it is used to justify inconsistent language constructs. If I had a nickel for every time someone said, "you don't need to change the language, just use a pre-processor" I'd drown in them. Point one: any such preprocessor needs to be standardized to the level that the language is, or it defeats the purpose of the language. Point two: If such a preprocessor *is* in fact standarized to the level that the language is, there is no discernable difference between changing the language and adding a preprocessor. Point three: the argument is that assignment should not be overloadable because it is not understandable (though more readable). It makes no real difference whether you put assignment overloading into a pre-processor or into the language. The pre-processing source is what will be maintained and used. It is identically as understandable if the language is changed as it is if a processing step is added. Perhaps more so. If the language is changed, no one will *assume* that assignment cannot be overloaded. Tacking on a preprocessor is the coward's way out. >a sad commentary that there are still Ada programmers out there who >still do not understand the need for and utility of an APSE. You can It's needed because the language was designed in an inconsistant and inflexible manner in the first place. What would you say about a preprocessor that converts C into Ada. Is programming in C then as good as programming in Ada? (don't laugh, it can be done, especially if you use unchecked programming) I don't think so. Another change I'd like to see. (upward compatible this time) Allow: if A in B | C | D | Q | Y | N then ... end if; I.e. an extension of the membership idea. It's ridiculous to me that case A is when B | C => ... end case; is valid but the above (or some equivilent) is not. I argue that such a construct is both more readable and more understandable than if A = B or A = C or else ... or else A = N then ... end if; and also makes the Ada language more internally consistent. (and thus easier to use) I also argue that compiler vendors are likely to implement the former more efficiently than the latter. This is especially true when the comparands are of a large enumerated type. (hashing, and all) Anyway, enough diatribe for today. -- "Our little lives get complicated It's a simple thing Simple as a flower And that's a complicated thing" ../ray\..