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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4961da398a273222 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-02-07 18:06:54 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!newsserver.jvnc.net!nntpserver.pppl.gov!princeton!rutgers!uwvax!zebu.heurikon.com!news.sprintlink.net!howland.reston.ans.net!news2.near.net!news3.near.net!noc.near.net!ray.com!news.ray.com!news.ed.ray.com!swlnews.msd.ray.com!swlvx2!jgv From: jgv@swl.msd.ray.com (John Volan) Subject: Re: Ada self-referential operators Sender: news@swlvx2.msd.ray.com (NEWS USER) Organization: Raytheon Company, Tewksbury, MA Message-ID: References: <3gnkjb$gso@miranda.gmrc.gecm.com> <3grqrf$jkd@gnat.cs.nyu.edu> Date: Wed, 8 Feb 1995 02:06:54 GMT Date: 1995-02-08T02:06:54+00:00 List-Id: ka@socrates.hr.att.com (Kenneth Almquist) writes: >Robert Dewar wrote: >> It is not that I think :+= is peculiar because it is not in the RM, rather >> +:= is not in the RM because it is peculiar, i.e. it would be VERY difficult >> to put it in without running into nasty semantic ramifications. > >Perhaps I'm missing them. What about the following rules? > >1. For each function of the form > > function "+"(L: type_1; R: type_2) return type_1; > > where type_1 is not limited, implicitly define: > > procedure "+:=" (L: in out type_1; R: in type_2) is > begin > L := L + R; > end "+:="; > > These implicit definitions should behave similarly to the implicit > definitions of "/=" which occur in Ada 83 and Ada 95. Explicit > defintions of "+:=" are illegal. > >2. If a statement of the form "A +:= B;" is encountered, treat it as > the procedure call "+:="(A, B). > Kenneth Almquist First of all, what you're proposing is not quite analogous to the relationship between "=" and "/=". In the case of equality and inequality, both are functions, so one function is derived from another. In the case of "+" and "+:=", the first is a function while the latter is a procedure, so you're proposing to have a procedure be implicitly derived from a function. A bit of a conceptual leap... Well, okay, that's a minor point. However, who says that implicitly deriving one subprogram from another is a *good* thing? Who says that doing *anything* implicitly is a good thing? Isn't it a fundamental tenet of the design of Ada to *avoid* "implicitness" as much as possible? Realize that the relationship between "=" and "/=" is *unique* within Ada. Isn't it possibile that this is because there is something special about these functions, something which should not necessarily set a precedent? The notion of "equality" has some particularly loaded conceptual baggage to it, and there may be important reasons for guaranteeing the meaning of "inequality". (I'll defer to others with more language-lawyer experience to take up this point.) But just because it's desirable to have a strong relationship between "=" and "/=" doesn't mean that it's desirable to establish strong relationships between other operator symbols. For instance, why bother defining binary "-" (subtraction)? Can't it just be derived from from binary "+" (addition) and unary "-" (negation)? In fact, by this argument, shouldn't we *prohibit* overloading of subtraction and *require* it to be automatically defined as: function "-" (Left : in Type_1; Right : in Type_2) return Type_3 is begin return Left + (- Right); end "-"; whenever the following are available: function "+" (Left : in Type_1; Right : in Type_2) return Type_3; function "-" (Right : in Type_2) return Type_2; pragma Flame (On); pragma Implicit_Smiley (On); But here's my *real* objection to all this talk about "self- referential operators": A symbol like "+:=" is a YAFO -- Yet Another Funky Operator! (You can replace "Funky" with something ruder if you're so inclined. :-) Why do we need YAFOs like "+:=" and "*:=" when you can write perfectly good procedures with perfectly readable names like "Increment" and "Multiply"? If you want such procedures to be automatically supplied by the language, consider building them in as attributes of numeric types, as I suggested a few posts back, e.g.: procedure T'Increment (X : in out T; By : in T); procedure T'Multiply (X : in out T; By : in T); What's so hard about saying something like: Integer'Increment (Long_Complex_Name_Of_An_Integer_Varable, By => 2); What tremendous advantage do we gain by being able to say something like: Long_Complex_Name_Of_An_Integer_Variable +:= 2; I never cease to be amazed (and disgusted) at how enamored some people in this industry seem to be about using arbitrary sequences of special characters for just about everything under the sun. Who says it's *desirable* to load up a language with a lot of cryptic "mathematicalese"? Doesn't anyone remember how *hard* it was to learn math, way back in grade school? IMHO, the operators that Ada currently supplies ought to be considered a grudging concession to the algebraic indoctrination we all suffered as children. The only reason they are there at all is because they've been beaten into our heads for so long that it is impossible to escape them. The last thing they should be viewed as is as a precedent for yet more operators. Consider a related issue: Doesn't anyone remember what a struggle it was to internalize things like arithmetic precedence rules? If precedence rules are so easy to digest, then why did the designers of Ada refuse to establish different precedence levels for logical "and" and "or", by analogy with the precedence distinction between "+" and "*"? Why are we *forced* to use parentheses in any expression that mixes "and" and "or"? Answer: Because nobody back in grade school indoctrinated us in Boolean algebra! If you think about it, the fact that multiplication takes precedence over addition is really a very arbitrary rule. It is perfectly possible to devise a completely self-consistent algebraic system in which addition has higher precedence. Likewise, it is possible to devise two completely self-consistent Boolean algebra systems, one in which "and" takes precedence over "or", and another in which "or" takes precedence over "and". There's no a priori reason for favoring one system over the other. However, the precedence of multiplication over addition is so ingrained in our culture that you can guarantee that every Ada programmer will automatically understand the meaning of A + B * C without having to insert any parentheses. On the other hand, there is no such cultural bias distinguishing "and" and "or", so there is no guarantee that a programmer will automatically understand the meaning of A and B or C without clarifying it with parentheses. By the same token, most educated people don't come with a built-in, ingrained understanding that, for instance "<<" sometimes means bitwise left-shift, but other times means write-to-a-stream. Or that "*" sometimes means multiply, sometimes means declare-a-pointer, and other times means dereference-a-pointer. Or that "&" sometimes means a reference but other times means bitwise-"and"-on-an-integer, whereas "&&" means logical-"and"-on-a-boolean. Ad nauseum. Look, if you want to be able to write gobbledegook like: A<>(--E[F++],G)-H%(!I:J=K?L=M,N); then go get yourself a C/C++ [sic] compiler. Heck, why go half-way -- why don't we all just program in APL? Ada, on the other hand, was designed for *readability*. YAFOs -- JUST SAY NO!!!! pragma Implicit_Smiley (Off); pragma Flame (Off); Oh boy, now I've done it! Here come the language-wars! :-) -------------------------------------------------------------------------------- Me : Person := (Name => "John G. Volan", E_Mail_Address => "jgv@swl.msd.ray.com", Employer => "Raytheon", Affiliation => "Enthusiastic member of Team-Ada!", Shameless_Controversial_Marketing_Slogan_For_Favorite_Language => "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>" & "Inheritance, hierarchical name-space, generic templates, type-safety, " & "readability, C/C++/COBOL/FORTRAN interoperability, numeric precision, " & -- ^^^^^^^^^^^^^ a n d n o Y A F O s ! ! ! :-) "multi-threading, distributed systems, real-time, safety-critical ... " & "<< A d a 9 5 : Y o u n a m e i t , i t ' s i n t h e r e >>", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my employer, so using them would be " & "totally erroneous ... or would that be a bounded error? :-) "); --------------------------------------------------------------------------------