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-23 07:14:05 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!attbi_s52.POSTED!not-for-mail Message-ID: <3F97E1D8.1020509@comcast.net> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: += in ada References: <3F900F35.50203@comcast.net> <3F92B607.809@comcast.net> <3F937806.9080205@comcast.net> <3F953687.9070406@comcast.net> <3F96DF31.5040501@comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s52 1066918444 24.34.139.183 (Thu, 23 Oct 2003 14:14:04 GMT) NNTP-Posting-Date: Thu, 23 Oct 2003 14:14:04 GMT Organization: Comcast Online Date: Thu, 23 Oct 2003 14:14:04 GMT Xref: archiver1.google.com comp.lang.ada:1511 Date: 2003-10-23T14:14:04+00:00 List-Id: Russ wrote: > I still don't understand where you got that impression. For overloaded > "+=", I don't see how it could be anything other than a procedure. All that discussion about how A += 1 is more efficient than A := A + 1; The procedural version is theoretically significantly less efficient than A := A + 1; although most compilers will, when asked, do the inlining that makes it exactly equivalent. If you think that A += 1 is more efficient you are talking about augmented assignment. (Assignment with the addition as a side-effect.) As I showed, in Ada if you try to generalize that to cover all cases, there are insoluble problems. > On the other hand, for built-in types such as integer and float (and all > the scalar types derived from them), I would expect "+=" to be > automatically available. It would be silly to require the programmer > to define all those. I hope that is clear too. If you check the tread carefully, you will find articles where I and at least one other ARG member discussed adding Inc as a predefined operation for Integer types. Several ARG members favor it, others think it is unnecessary. We could also discuss whether there should be one procedure with a default parameter: procedure Inc (L: in out Integer; R: in Integer := 1); or two separate versions. Personally I think the one parameter version is enough. Of course, the predefined operation would only be available for predefined Integer types. But we would probably have to consider whether it should be supported for other language defined types and if so how. Take System.Address for example. This "extra" overhead of any language change is one reason that the ARG seems so conservative. In private discussions, some of the language changes considered look pretty revolutionary. If the idea multiplies in scope, then it is usually discarded. As a horrible example, AI-2 and AI-7 from the Ada 83 days were seemingly simple issues that multiplied out of control. I remember one (back then LMC) meeting where AI-2 and AI-7 plus AIs that were separated out of them occupied one entire volume of maybe 200 pages, and the other AIs to be discussed were a second volume. As I recall we found a "simple" solution to AI-7. It basically left when a certain constraint check was performed undefined, but required the check. All the implementors who were following the discussion knew that for the problem cases there was only one "natural" place to do the check. For the rest we didn't care which of the natural places it was easiest for the compiler to the check. Back to Inc. If there was sufficient demand from users, I am sure Inc would be added in the revision currently in progress. However, I feel that there are a number of more important language changes that are "on the bubble" and may not make the cut due to limitations on how big a change we can make. The really hard question is does this discussion indicate a groundswell of user support for Inc, a lot of opposition to it, or just a lot of idle discussion. Notice that there are several major changes that almost certainly will make it in, and at least one that is "iffy." Adding Inc would be a minor change. Adding ++ would be a significant change, and augmented assignment would be a huge change, if we could figure out how to make it work. -- Robert I. Eachus "Quality is the Buddha. Quality is scientific reality. Quality is the goal of Art. It remains to work these concepts into a practical, down-to-earth context, and for this there is nothing more practical or down-to-earth than what I have been talking about all along...the repair of an old motorcycle." -- from Zen and the Art of Motorcycle Maintenance by Robert Pirsig