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,38fc011071df5a27 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-03 13:50:25 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stueberl.de!newsr1.ipcore.viaginterkom.de!btnet-peer1!btnet-peer0!btnet-peer!btnet!news-hub.cableinet.net!blueyonder!internal-news-hub.cableinet.net!news-binary.blueyonder.co.uk.POSTED!53ab2750!not-for-mail User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: Ideas for Ada 200X From: Bill Findlay Newsgroups: comp.lang.ada Message-ID: References: <6a90b886.0305262344.1d558079@posting.google.com> <6vWcnTWjF83bD0qjXTWcpA@gbronline.com> Mime-version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Date: Tue, 03 Jun 2003 21:49:20 +0100 NNTP-Posting-Host: 80.195.75.181 X-Complaints-To: abuse@blueyonder.co.uk X-Trace: news-binary.blueyonder.co.uk 1054673424 80.195.75.181 (Tue, 03 Jun 2003 20:50:24 GMT) NNTP-Posting-Date: Tue, 03 Jun 2003 20:50:24 GMT Organization: blueyonder (post doesn't reflect views of blueyonder) Xref: archiver1.google.com comp.lang.ada:38553 Date: 2003-06-03T21:49:20+01:00 List-Id: On 3/6/03 20:39, in article bebbba07.0306031139.21306c32@posting.google.com, "Russ" <18k11tm001@sneakemail.com> wrote: >> 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. ... Sorry, I don't get this. Can you give an example? How can 'X := X + 1;' be clarified by introducing an intermediate variable? >> 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. You've lost me. >> 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). The only difference between the 'idem' proposal and the use of ?=, *in the context of my assumptions*, is syntactic (i.e. 'idem' is syntactically much more general). There is no semantic difference, and therefore no potential performance difference whatsoever (for the subset that is covered by ?=). >> 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? Yes, since it means exactly the same thing, in the context I explicitly set out here. You want to make a different case, involving overloaded assignment; but I chose not to take part in that argument. >> 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. ... Speak for your own position. 8-) > "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? The big deal is (1) you lose all the advantages I listed; and (2) 'idem' handles easily the cases that assignment operators fail to handle. General solutions are better than special-case fixups. -- Bill-Findlay chez blue-yonder.co.uk ("-" => "")