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.5 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4961da398a273222,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-02-01 21:10:37 PST Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!news.sprintlink.net!pipex!uknet!hrc63!gmrc.gecm.com!valiant!bill From: bill@valiant (R.A.L Williams) Newsgroups: comp.lang.ada Subject: Ada self-referential operators Date: 1 Feb 1995 09:34:35 GMT Organization: GEC-Marconi Research Centre Message-ID: <3gnkjb$gso@miranda.gmrc.gecm.com> NNTP-Posting-Host: valiant.gmrc.gecm.com X-Newsreader: TIN [version 1.2 PL1] Date: 1995-02-01T09:34:35+00:00 List-Id: In article <3g9nir$fpl@gnat.cs.nyu.edu> RobertDewar wrote: : "The "+=" operator is MADE for this statement, but its ONLY benifit is : to save me 11 characters in my source file." : that's going a little far, the purpose of += is much more than saving : characters, it abstracts the operation to be an increment instead of : a computation and assignment that just happens to be an increment. [long and convincing rationale for += deleted] : but still I think it is the right choice not to complicate the language to : add these peculiar forms. Note that in C, where + cannot in any case be : redefined, they are cleaner, and in algol-68, where parameters are strong : enough (using ref) to describe variables, they are also cleanly addable. You seem to be saying that 'because the LRM doesn't have these operators there is something peculiar about them'. Forgive me if that was not your intent. I'm very much in favour of these concise representations of what the programmer really intends. I was recently a team leader on a project (written in C, but that is not really relevant) where, because of constraints on the target hardware, there was 100% code inspection before attempting to integrate. Now when you're faced with the quantities of code that we had and the task of verifying it against design specs and Yourdon analysis (the design methodology retained p-specs into the coding stages as design information) then you *really* appreciate every labour saving device that the coder can introduce! : Often in a lanuage there are things that would be nice but don't fit very : well. If nice is *very* nice, then sometimes we are willing to accept a : complex wart in the language, but if nice is only a *little* nice, it's : better to opt for cleanliness, and this is such a case I think in Ada 95. So far as I can see, the main reason that allowing "+=" etc. to be overloaded does not fit in with the rest of Ada is that ":=" cannot be overloaded. Well, this again is an unfortunate oversight. In linear algebra packages, for example, it is frequently desirable to have an implicit garbage collection mechanism for temporary results. The assignment operator is a good place to put this. In C++ the overloaded assignment operator is often used to implement constraint checking. While this is not as valuable in Ada, I know of at least one military C3I system where a particular type, TX frequency, must be constrained into three non-contiguous bands. This would be hard to represent without an explicit test in Ada. (Since most of the code for that particular system was originally written in Fortran I suppose the issue never arose!) Admittedly, the situation in C++ is different from Ada. In C++ every expression has a value, and an assignment counts as an expression. It is therefore logical to allow overloading the assignment operator as a function. In Ada, OTOH, ":=" would need to be overloaded by a procedure, making it unique amongst the 'predefined operators'. I don't see any other reason why this is not a 'clean' extension. Perhaps ":=" wouldn't stick out so much if it had "+=" etc. to keep it company? Still, I suppose we must accept the consensus view on Ada9x. Perhaps in Ada0x....? Bill Williams