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-Thread: a07f3367d7,c26a0bb87e0a1da4 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Conversion from Ada95 to Ada05 Date: Tue, 23 Feb 2010 16:12:12 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <5e46b3e8-f7ea-45a6-a884-6882f6ec8295@c16g2000yqd.googlegroups.com> <8432d8b0-acd0-439f-8366-d72f53571f90@k18g2000prf.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1266959521 26198 192.74.137.71 (23 Feb 2010 21:12:01 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 23 Feb 2010 21:12:01 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:17J3Z55O3i67h3Pbxdq0i/mRbXo= Xref: g2news1.google.com comp.lang.ada:9297 Date: 2010-02-23T16:12:12-05:00 List-Id: "Randy Brukardt" writes: > wrote in message > news:Pine.LNX.4.64.1002231026050.9207@medsec1.medien.uni-weimar.de... > ... >> I am curios: Which of your old favorites didn't work anymore? Which Ada95 >> patterns occur in practice, which are incompatible to Ada05? > > I can't speak for John, but the main incompatibility that we hear about was > the elimination of return-by-reference. While it didn't make much sense, > people managed to make it work for various things and those patterns don't > work anymore. Right, but it's not just return-by-reference. If you return a local limited object, that's legal in Ada 95, but illegal in Ada 2005. If the limited type is immutably limited, that's the return-by-ref case. (Immutably limited means it's really limited deep down -- like a limited private completed with a limited record.) Otherwise (like a limited private completed with an integer type) it's return-by-copy. In AdaCore's test suite, there are something like a couple dozen tests that run into this incompatibility, out of some 15,000 tests. It turns out that the return-by-ref case is something like 1/3 of those, and the return-by-copy case is 2/3. (I measured this when I was involved in implementing the new Ada 2005 build-in-place return feature, but I don't remember the exact numbers). I think it was a language design mistake to apply this rule to the return-by-copy case. If it applied only to the return-by-ref case, it would be less incompatible. Of course, that would break privacy, which is evil. But incompatibilities are even more evil, in my opinion. It would work, because the limited-but-not-inherently-limited case is not build-in-place in Ada 2005 -- it's still return-by-copy. On the other hand, the workarounds for the return-by-copy case are fairly painless -- for example, you can make the type nonlimited. That sort of makes sense anyway, since the limitedness is a lie -- "limited" is supposed to mean "cannot copy", but in fact clients CAN copy in this case (and there's a famous Henry Baker paper about that from Ada 83 days). > We're trying to come up with a sane way to have the same effect (returning > an access value with a limited lifetime and without the need for explicit > dereferencing) for Ada 2012. Hopefully, that capability will allow the > holdouts to come along... Yup. - Bob