Re: Ada self-referential operators

[jgv@swl.msd.ray.com (John Volan)]

ka@socrates.hr.att.com (Kenneth Almquist) writes:

>Robert Dewar <dewar@cs.nyu.edu> 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<<B* *C^=D>>(--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? :-) ");
--------------------------------------------------------------------------------