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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,54889de51045a215 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-07 15:22:11 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: 18k11tm001@sneakemail.com (Russ) Newsgroups: comp.lang.ada Subject: Re: += in ada Date: 7 Oct 2003 15:22:10 -0700 Organization: http://groups.google.com Message-ID: References: <3F7316F7.219F@mail.ru> <17cd177c.0310010606.52da88f3@posting.google.com> <49cbf610.0310070205.2937e71a@posting.google.com> NNTP-Posting-Host: 128.102.146.44 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1065565331 4787 127.0.0.1 (7 Oct 2003 22:22:11 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 7 Oct 2003 22:22:11 +0000 (UTC) Xref: archiver1.google.com comp.lang.ada:407 Date: 2003-10-07T15:22:10-07:00 List-Id: "(see below)" wrote in message news:... > On 7/10/03 12:56, in article slrnbo5afo.o7.lutz@taranis.iks-jena.de, "Lutz > Donnerhacke" wrote: > > So I have to conlude, that the whole "idem" Idiom is useless at all. > > Some time ago, I posted this: > > > 1. It lets the programmer indicate that the occurrences of the LHS in the > > RHS are *necessarily* the same, and not contingently so, which makes the > > code more self-documenting. The proposed augmented assignment operators ":+", ":-", ":*", and ":/" do even better than that. They make the LHS and RHS one and the same. > > 2. It removes a source of error in transcribing the LHS multiple times. Ditto for ":+", etc. > > 3. It allows more concisely readable code when the LHS is lengthy. Ditto for ":+", etc. > > 4. It provides functionality that it only partially available by means of > > much clumsier renaming declarations, because not all objects can be renamed. Ditto for ":+", etc. > > 5. It requires the compiler to evaluate the lvalue of the LHS once and reuse > > that lvalue as often as needed to evaluate the RHS. This has three potential > > benefits: shorter code, faster execution, and once-only invocation of any > > side effects. > > 6. It might make it somewhat easier for the compiler to generate > > update-in-place object code, where the target architecture allows that and > > where it offers a performance advantage. Replace "might" with "will" for ":+", etc. Augmented assignment gives control over to the programmer, where it belongs, who can guarantee update-in-place efficiency with proper basic design, as opposed hoping or praying that every compiler does the job right. > > 7. It provides all the utility of C's multitude of combined assignment > > operators with one small, compatible change to the syntax of operands. > > (I specify C, rather than C++, to avoid getting into a argument about > > overloading assignment). > > 8. It allows the expression of useful forms that C's combined assignment > > operators cannot achieve (e.g. X := 1 - idem;). Yes, but the vast majority of uses in practice will be for simple incrementing, multiplying in place, etc. The "idem" construct is overkill. I have no objection to the proposal, but I think it would be a mistake to let it crowd out the simpler augmented assignment operators. Repeat after me: Augmented assignment is available and WIDELY USED in C, C++, Java, Perl, and Python, perhaps the 5 most popular general-purpose programming languages ever designed. Is it *possible* that 98% of the programmers out there might know *something* that Ada programmers don't?