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.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: Brian Rogoff Subject: Re: Subverting 'Access for Sub-programs Date: 1999/08/05 Message-ID: #1/1 X-Deja-AN: 509468329 References: <37A71EF1.2201@dera.gov.uk> <37A7FDE8.4F5@dera.gov.uk> <7o9vrv$qgt$1@wanadoo.fr> <7oc5ih$6mb$1@wanadoo.fr> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.ba.best.com 933916142 199 bpr@206.184.139.136 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-08-05T00:00:00+00:00 List-Id: On Thu, 5 Aug 1999, Robert A Duff wrote: > "Jean-Pierre Rosen" writes: > > > OK, I understand your problem better (full examples always help :-) > > Of course, you realize that "Integrator" could store the pointer to function > > to any global variable, possibly resulting later in random branches. > > This is not true of either of the proposals the design team proposed. That is true, and in the example I posted I used 'Unrestricted_Access is the most portable solution. Your limited access to subprogram would have worked fine, or even just Pascal style subprogram arguments (meaning, why confuse access types and subprogram types?). Your proposal to allow tagged limited types to be extended in nested scopes was also pretty cool, though I'd like something like that in addition to downward funargs. But downward funargs alone are way useful; given the ability to use downward funargs safely I'd be more likely to use funargs to parameterize the behavior of a primitive subprogram of a tagged type than a nested extension. > Your comment is, of course, true of 'Unchecked_Access on subprograms, > but please note that the design team never wanted to allow that. We > believed that "call backs" and "downward closures" are two separate > features, that each need their own (different) set of restrictions to be > safe. Call backs can't point to local subprograms, but they can be > copied anywhere you like. Downward closures can point to local > subprograms, but they can't be copied into global places. The language > ended up with call backs, but not downward closures. > > Your comment is, of course, also true of what we ended up with -- > 'Unrestricted_Access, which is neither safe nor portable -- it's even > less checked than 'Unchecked_Access. That's what I meant when I said > "too bad..." in another posting. I think that the use of the feature is justified. If people don't think the omission of downward funargs is a flaw, it will never get fixed. Unrestricted_Access is a way to get the hint across. Modify GNAT to use your safe proposal and I'll switch :-) It was probably the right choice at the time (1990-1995) to exclude downward funargs, and Robert Dewar's statement about the pain some implementor's would have suffered seems reasonable enough. It won't seem reasonable much longer though. -- Brian