Re: An observation of Ada (may offend)

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

hebert@prism.uvsq.fr (Renaud HEBERT) writes:

>In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com (R.A.L Williams) writes:
>|> e. No short cut operators (+= etc.) -- sorry, we've had this debate
>|> already in another thread, I've heard the objections, I still like the
>|> operators.

>Could someone summarize the objections against short cut operators, because
>I think that they are great and I 'm quite surprise that they don't exist in
>Ada. No need to start a flamewar, I suppose that as with many construct there
>are pros and cons. It's just that I can't see why those operators could be bad.

There's nothing wrong with the notion of short-cut arithmetic
*procedures*.  It's the idea of short-cut arithmetic *operators* that's
the problem.  

I think it would be quite nice if Ada included some built-in
procedures that provided short-cut arithmetic.  Perhaps these could be
in the form of attributes: For every numeric type T, we'd have
attribute procedures such as:

  procedure T'Increment (What : in out T);            -- analogous to ++ in C
  procedure T'Decrement (What : in out T);            -- analogous to -- in C
  procedure T'Increment (What : in out T; By : in T); -- analogous to += in C
  procedure T'Decrement (What : in out T; By : in T); -- analogous to -= in C
  procedure T'Multiply  (What : in out T; By : in T); -- analogous to *= in C
  procedure T'Divide    (What : in out T; By : in T); -- analogous to /= in C

Barring that, it wouldn't be too hard to "roll your own" solution by
writing reusable generic templates for these subprograms.

But to make these into *operators* would entail some difficulties for Ada:

(1) Operators (at least in Ada terms) are functions; they are
subprograms that return a result.  But the point to these short-cut
arithmetic routines is to cause a side-effect on one of their
parameters.  Having a function that causes a side-effect is somewhat
against Ada's design "philosophy".

(2) IMHO, the whole notion of a return value from this kind of
subprogram is totally extraneous anyway.  The whole point of such a
subprogram is, after all, to cause that side-effect, so the idea of an
incidental return value just adds an unnecessary complication.
Witness the contortions C++ gets into due to the subtle difference
between pre-increment ( ++x ), which returns the value of x *after*
incrementing it, versus post-increment ( x++ ), which returns the value of
x *before* incrementing it.

(In fact, this leads me to pose a question: What is the value of C++?
Does it really provide an *improvement* on C, or does it just yield the
*same* *result*?  Maybe they should have called it ++C instead!!!)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)

(3) Operators are special symbols, with special syntax (infix, prefix,
postfix), and special semantics (precedence levels).  The syntax and
semantics of the operators we all learned in grade school ( + - * / )
were hard enough to master.  Why gratuitously invent new ones, when you
can do the same job using ordinary subprogram syntax and semantics?
(See my proposed attribute procedures above.)  The only benefit of
short-hand operator symbols is that they make it more convenient for
someone to *write* code -- at the cost of *readability*.  The
philosophy behind the design of Ada was to optimize for readability,
even at the expense of writability, on the assumption that more time
will be spent trying to read and understand Ada code than to write it.

				-- John Volan

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Favorite_Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
    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? :-) ");
--------------------------------------------------------------------------------