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=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,75a8a3664688f227 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-14 06:44:03 PST Path: supernews.google.com!sn-xit-02!supernews.com!bignews.mediaways.net!news.nikoma.de!tiscalinetde!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!grolier!btnet-peer0!btnet-peer!btnet!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: Robert Dewar Newsgroups: comp.lang.ada Subject: Re: Parameter Modes, In In Out and Out Date: Sun, 14 Jan 2001 14:33:59 GMT Organization: Deja.com Message-ID: <93sdcn$dr0$1@nnrp1.deja.com> References: <3A57CD7F.2228BFD5@brighton.ac.uk> <938p3u$omv$1@nnrp1.deja.com> <93cagm$c1j$1@nnrp1.deja.com> <93e4e6$ucg$1@nnrp1.deja.com> <93encq$brm$1@nnrp1.deja.com> <93f6ar$m44$1@nnrp1.deja.com> <93flab$2mh$1@nnrp1.deja.com> <93fqau$6m2$1@nnrp1.deja.com> <93h9mo$bbm$1@nnrp1.deja.com> <93il87$iqo$1@nnrp1.deja.com> <93k6dv$qt6$1@nnrp1.deja.com> <93ko49$auq$1@nnrp1.deja.com> <93modu$36k$1@nnrp1.deja.com> <93n2co$alq$1@nnrp1.deja.com> <93q39q$oq0$1@nnrp1.deja.com> <93q6cd$r3k$1@nnrp1.deja.com> <3A6140CB.63EE9B8F@acm.org> NNTP-Posting-Host: 205.232.38.14 X-Article-Creation-Date: Sun Jan 14 14:33:59 2001 GMT X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; U) X-Http-Proxy: 1.0 x65.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 X-MyDeja-Info: XMYDJUIDrobert_dewar Xref: supernews.google.com comp.lang.ada:3997 Date: 2001-01-14T14:33:59+00:00 List-Id: In article <3A6140CB.63EE9B8F@acm.org>, Jeffrey Carter wrote: > Brian Rogoff wrote: > However, in the area of passing an access-to-subprogram value > to a subprogram, there is no way to get around the rules. > This is an unfortunate deviation from the basic philosophy. "the basic philsophy" The word "the" here is mischosen. The Ada design follows a set of guidelines (basic philosophical principles if you really want to get that grandiose), and what you refer to is just one of them. Another is ease of implementation, and in particular, an easy path for migration of Ada 83 technologies. Tuck once said that he was dubious about the possibility of adapting Ada 83 technology to Ada 95, and you will notice that Averstar (Intermetrics) did indeed start from scratch rather than adapt their previous Ada 83 technology. GNAT also started from scratch, but that's a bit misleading, because there was no production Ada 83 compiler on which GNAT could have been built (Ada/Ed was a different kind of beast). However, Tuck was pessimistic, we have seen that it is possible to adapt Ada 83 technologies to Ada 95, and there is more than one example, a notable example is the Rational technology. A critical guideline (philosophical principle?) was that existing Ada 83 runtime models be reusable as far as possible. In the case of Unchecked_Access, it is trivial for an implementation to omit a check, so that is no big deal. But Unrestricted_Access (the GNAT attribute that gives Jeffrey what he wants) is not just a matter of omitting a check, it requires handling non-local references correctly. Now in the case where you use a static link approach, as GNAT does (since that's what gcc had chosen to use for GNU C), then it is indeed trivial to implement Unrestricted_Access, and indeed for GNAT, it is zero work, just a matter of omitting an accessibility check. But for run-time models using displays, implementing Unrestricted_Access is tricky (one vendor at one Ada 95 meeting used stronger language, I believe "nightmare" was the word used :-) If you ask your vendor "Gee, I kind of like the ACT Unrestricted_Access attribute, can you implement this, the answer will hugely depend on whether displays or static links are used". So yes, the failure to provide this capability is uncomfortably inconsistent with one guideline, but was at the time mandated by another guideline. Was it a good idea to have this restriction? Hard to say in this particular case. It is certainly the case where transitional implementation concerns of existing vendors most specifically impacted the Ada 95 design in what I think most people would say was a negative manner (certainly we find that the 'Unrestricted_Access attribute is invaluable in many contexts). Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/