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: Robert A Duff Subject: Re: Subverting 'Access for Sub-programs Date: 1999/08/05 Message-ID: #1/1 X-Deja-AN: 509227907 Sender: bobduff@world.std.com (Robert A Duff) References: <37A71EF1.2201@dera.gov.uk> <37A7FDE8.4F5@dera.gov.uk> <7o9vrv$qgt$1@wanadoo.fr> <7oc5ih$6mb$1@wanadoo.fr> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-08-05T00:00:00+00:00 List-Id: "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. 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. - Bob -- Change robert to bob to get my real email address. Sorry.