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: bobduff@world.std.com (Robert A Duff) Subject: Re: Q: access to subprogram Date: 1996/07/29 Message-ID: #1/1 X-Deja-AN: 170856835 references: <4rb9dp$qe6@news1.delphi.com> <4t9un9$imn@goanna.cs.rmit.edu.au> <4tha38$1p@goanna.cs.rmit.edu.au> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-07-29T00:00:00+00:00 List-Id: In article <4tha38$1p@goanna.cs.rmit.edu.au>, Richard A. O'Keefe wrote: >I do not call that a logical conclusion. >"All useful mechanisms which have ever been *commonly used* should be >included" comes closer to being a reasonable generalisation of what I >wrote. Fair enough. >Ada 95, but arrived in an unusable fashion because that feature was >confounded with another feature, namely access-to-procedure. I don't understand why you say that. It's not historically accurate. The MRT was well aware of the two different features, and proposed two different features, with different sets of rules. The "passing nested procedures as params" features was not included in the final design. You can complain about that fact (and I will agree), but you shouldn't complain that the language designers "confounded" the two features -- they didn't. >Ahem. My benchmark is solely concerned with DOWNward closures, not full >closures. Just because I ran the benchmark in a language which supports >full closures doesn't mean that the benchmark itself used that power. Right. I just meant that your benchmark shows that it's possible for downward closures to be efficient even in a language that has full closures (a distributed overhead issue). We already knew that, of course -- there are compilers for many languages that require heap-allocated stack frames in general, but are capable of avoiding that it many cases. And anyway, your benchmark is just one example, and thus not very convincing on this point. >Well, the classic application of full closures in Scheme is OOP. Which of course doesn't convince *me* that full closures are a Very Good Thing, since I'm happy to have the OOP features built in, and do the "similating" in the other direction. >My argument about simulation extends to this as well: it is better to have >a module construct so that the compiler knows what you are up to and can >check that you got it right. ... And apparently you agree. Either one can be used to "simulate" the other. So, is there any reason to have both? - Bob