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,99ab4bb580fc34cd X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Q: access to subprogram Date: 1996/07/30 Message-ID: #1/1 X-Deja-AN: 170932137 sender: news@organon.com (news) references: <4rb9dp$qe6@news1.delphi.com> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-07-30T00:00:00+00:00 List-Id: In article <4tha38$1p@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes: [...] > simulate in Ada 83, can demonstrably be implemented efficiently by a > compiler (5 seconds for the program in Scheme compiled by Stalin into C > then into SPARC code by SPARCompiler C SC4.0, compared with 18 seconds for > the program in Ada compiled by GNAT 3.04 GCC 2.7.2), was expected for > Ada 95, but arrived in an unusable fashion because that feature was > confounded with another feature, namely access-to-procedure. [...] > > The point is, you don't *have* to tangle them up, and the restrictions > that are necessary for the one (procedure pointers) if you don't want > to support full closures are NOT necessary for the other (procedures > as parameters). Exactly so. What is more, this particular scheme was in fact considered: access to procedure parameters. It would have fit fairly well with the language (maybe even rather well) in this area. But it seems that certain of those involved becamed "obsessed" with the view that the only way to achieve the effect was with some sort of access-to-procedure _type_ (the so called limited access type in particular). > Not only that, you *can* tangle them up in a different way from the > Ada 95 way: you say that the lexical level of a procedure parameter > is the lexical level of the procedure in whose header it appears, > and forbid (copies) of that parameter outliving the callee. Meaning simply that only procedures at or below the lex level of the procedure P with the parameter could be legally supplied in a call of P. I suppose in this context (still involving an access type) the access to subprogram type to which the procedure access would belong would also have to be at or below P (which would effectively cover the stuff in the first sentence...) > So it would have been possible to have both procedure pointers with a > lexical level restriction (thus permitting an implementation in which > library level pointers are fully compatible with C) *and* unrestricted > passing of nested procedures as parameters. Certainly sounds right. So, what are the gotchas?... /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com