Re: Q: access to subprogram

[bobduff@world.std.com (Robert A Duff)]

In article <4tha38$1p@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> 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