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,efe03f20164a417b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-23 15:23:14 PST Path: nntp.gmd.de!stern.fokus.gmd.de!ceres.fokus.gmd.de!zib-berlin.de!news.mathworks.com!udel!gatech!purdue!news.bu.edu!news3.near.net!ray.com!news.ray.com!news.ed.ray.com!swlnews.msd.ray.com!not-for-mail From: jgv@swl.msd.ray.com (John Volan) Newsgroups: comp.lang.ada Subject: Re: An observation of Ada (may offend) Date: 23 Mar 1995 18:23:14 -0500 Organization: Raytheon Missile Systems Division Message-ID: <3ksvt2$299@swlrdv.msd.ray.com> References: <3kbkm1$41o@miranda.gmrc.gecm.com> <3kpkg9$88m@soleil.uvsq.fr> NNTP-Posting-Host: swlrdv.msd.ray.com Date: 1995-03-23T18:23:14-05:00 List-Id: 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? :-) "); --------------------------------------------------------------------------------