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,38fc011071df5a27 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-03 12:39:36 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: 18k11tm001@sneakemail.com (Russ) Newsgroups: comp.lang.ada Subject: Re: Ideas for Ada 200X Date: 3 Jun 2003 12:39:35 -0700 Organization: http://groups.google.com/ Message-ID: References: <6a90b886.0305262344.1d558079@posting.google.com> <6vWcnTWjF83bD0qjXTWcpA@gbronline.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 1054669176 28889 127.0.0.1 (3 Jun 2003 19:39:36 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 3 Jun 2003 19:39:36 GMT Xref: archiver1.google.com comp.lang.ada:38547 Date: 2003-06-03T19:39:36+00:00 List-Id: Bill Findlay wrote in message news:... > As I see it there are several arguments in favour of the 'idem' proposal: > > 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. If there is any question about that, the programmer can (and should) just use an explicit intermediate variable to make it clear. > 2. It removes a source of error in transcribing the LHS multiple times. So does "+=", "-=", etc. > 3. It allows more concisely readable code when the LHS is lengthy. So does "+=", "-=", etc. > 4. It provides functionality that it only partially available by means of > much clumsier renaming declarations, because not all objects can be renamed. So does "+=", "-=", 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. See 1. > 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. Might? "+=" definitely does. Once you have that ":=" in there, all bets for efficiency are off. Barring some very complicated form of artificial intelligence, ":=" pretty much rules out in-place operations (except perhaps for certain very restricted cases). > 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). But does it provide the same potential efficiency? > 8. It allows the expression of useful forms that C's combined assignment > operators cannot achieve (e.g. X := 1 - idem;). I think we're getting wrapped around the axle here, folks. No, the "assignment operators" do not handle all cases, but they do not need to. They are simply a nice shorthand notation for certain very common cases. The cases where they don't apply can be handled by other conventional methods. As for X := 1 - idem, one could simply write X := 1 - X. What's the big deal? Sure, if X had a longer name, then a shorter alias might be handy. I'm not completely opposed to this idea, but if it is adopted it should be adopted in *addition* to, not in lieu of, the assignment operators that have already proven their usefullness in several other very popular languages.