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,2308afbbe4ecec0b X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Subverting 'Access for Sub-programs Date: 1999/08/13 Message-ID: <7ovrd0$1d9$1@nnrp1.deja.com> X-Deja-AN: 512062724 References: <37A71EF1.2201@dera.gov.uk> <37A7FDE8.4F5@dera.gov.uk> <7o9vrv$qgt$1@wanadoo.fr> <7oc5ih$6mb$1@wanadoo.fr> <7oejga$28i$1@nnrp1.deja.com> <37AEF7BF.7BBC8E06@averstar.com> <7oqahu$3s0$1@nnrp1.deja.com> <37B1A8B5.219C9FE6@averstar.com> X-Http-Proxy: 1.0 x27.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Fri Aug 13 01:12:05 1999 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-08-13T00:00:00+00:00 List-Id: In article <37B1A8B5.219C9FE6@averstar.com>, Tucker Taft wrote: > I understood the point about not worrying about "display" > difficulties for *checked* language mechanisms. But for > something called "Unchecked_Access" I have always presumed > this is a mechanism that does the "obvious" thing, but just > doesn't perform any legality checks. Well it is clear that Unchecked_Access has to have clean clear semantics, as it does for variables. Who knows what this means in an implementation. For example, it is easy to imagine that Unchecked_Access might be very hard to implement and require lots of extra apparatus in an underlying environment that went out of its way to ensure safety (e.g. something like a JVM). > What you are proposing is that the "official" semantics > for Unchecked_Access impose a requirement that it "work" > whenever you are *dynamically* within the > scope of the called routine. This implies a significant > amount of mechanism on the part of display-based > implementations to implement this, as opposed to simply > eliminating the legality checks at the point of > 'Unchecked_Access. Yes indeed, but then I think if you allow general downward funargs you will need this extra mechanism in any case, and the proper implementation approach is probably to switch to static links. > In other words, *all* access-to-subp values might have > been produced by 'Unchecked_Access, so *all* calls > through such values in a display-based implementation > must take that into account. By adding 'Unchecked_Access, you > would be imposing a distributed overhead on all uses of > access-to-subp values, even if there is no 'Unchecked_Access > in the whole program, in the display-based implementation. > *That* is why I wouldn't want to call > this feature simply "Unchecked_Access." Once again, I am simply putting this proposal on the table I don't necessarily favor it. If you look back at my previous messages, I was simply laying out the solution space, not choosing a point in it!) I definitely agree that if the language was designed this way, i.e. in the way that gives a natural flexible, powerful, and efficient behavior if you use static links, then precisely it would be the case that implementations would pretty much be forced to use static links. The issue here is whether you want to continue to cripple the language (if you think the restrictions on procedure pointers to be crippling as many do) just to make it easier for old implementations using what is now a bad choice. One viewpoint that could be taken is that such limitations were appropriate early on in Ada 95, to increase the ease of transition, but now that transition is complete, it is not unreasonable to consider improvements that would cause some implementation difficulties in some compilers. After all almost any extension proposal will be harder for some compilers than others. > > I can see forcing implementors using displays to support a > more expensive mechanism under "new" circumstances, but I > can't see dramatically slowing down all uses of existing > access-to-subp values to support some additional feature. > That kind of distributed overhead of a feature is quite > unpleasant, especially as part of a language revision. We > made major efforts during the Ada 9X process to minimize new > features that imposed distributed overhead on old features. We are not talking about that here, we are talking about the limited case of old compilers not adapting to the more appropriate implementation strategy. The language should in abstract be designed so that there exists (at least one) efficient implementation strategy. That's quite a reasonable framework. In the case of the display issue, we went further, and decided to accomodate what, in the context of our language design effort, was very definitely a bad choice of implementation strategies. The question is whether you want to insist on this much more limited approach for ever. There are many other places in the language where changes in Ada 95 made things MUCH harder for some implementations (e.g. making sharing of generics much harder). > If we want an access-to-subp value that works any time you are > still within the "dynamic" scope of a subprogram, I believe we > should > make it a different kind of access type. Perhaps > type T is access all procedure ... > ^^^ > or some kind of pragma Unrestricted, or something. Even with > the static link approach, supporting Unchecked_Access on > access-to-subp > values requires doubling the size of all "top-level" > access-to-subp > values, or using some sort of "trampoline" trick. Creating a > trampoline that has the right lifetime is a fair amount of > work > as well, since the place of the 'Unchecked_Access is a bit > late. > I realize that GNAT has solved this, but I believe it takes > significant advantage of work already performed as part of the > GCC > nested procedure support. And all this makes the > 'Unchecked_Access > a significantly more "heavyweight" feature than is implied by > the name. It is far from being simply the moral equivalent of > an unchecked-conversion. I must say I really dislike the idea of procedure pointers being a different length at the top level and nested levels, sounds like a really nasty non-uniformity, so I would definitely avoid that. Note that the unchecked in unchecked_access to me is about lack of checks at run time, and indeed no checks are required at run time. As I noted earlier, I can easily imagine environments in which unchecked_access imposes a distributed overhead on all uses of access values! Really what we need to do at this stage is to try to get some idea of what the Ada user community wants. GNAT users are not the best source of help here, since the problem is already completely solved in GNAT (although of course not in a portable manner!) For users of other compilers, how much of a restriction is it to have access-to-procedure have the limitations of the current Ada 95 design, that is the question. I certainly know, as I have previously noted, that we make extensive use of Unrestricted_Access in the GNAT runtime (there are well over 100 instances in gnatlib). This is certainly not typical. First, a lot of it is low level system type code, second, you tend to use features that are available if it is the easiest way of doing things, and it does not always mean that you couldn't manage OK without them :-) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.