From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)
Subject: Re: Q: access to subprogram
Date: 1996/07/29
Date: 1996-07-29T00:00:00+00:00 [thread overview]
Message-ID: <4tha38$1p@goanna.cs.rmit.edu.au> (raw)
In-Reply-To: Dv99nL.6uu@world.std.com
bobduff@world.std.com (Robert A Duff) writes:
>>Whenever you simulate any mechanism,
>>...[all manner of evil happens]
>True, but the logical conclusion is that all useful mechanisms that
>anybody has ever thought of should be included in the language. One has
>to make a trade-off between a useful gizmo and language complexity
>(etc).
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.
>Anyway, I think this argument is getting confused between "downward
>closures" and "full closures". If I understand your example correctly,
>it needs downward closures, but not full closures.
Right. And that is all _I_ have ever been talking about in this thread.
As it happens, I like full closures, principally because they fit very
well with a "building blocks" approach to reuse, and because it greatly
simplifies things like graphic programming in Clean: it's the *compiler's*
job to worry about which things need to survive for a callback, not mine.
But I am not advocating full closures (or continuations, or first class
environments, or anything sexy) for Ada. All I am saying is that one
specific feature -- downward funargs -- has proven its usefulness over
many years in a lot of other languages, is demonstrably clumsy to
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.
You can have nested procedures as parameters without procedure pointers
(Pascal, Fortran, Algol 60).
You have have procedure pointers without nested procedures as parameters
(C).
You can have both without restriction (Lisp, Scheme, ML, Smalltalk).
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).
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.
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.
>I have argued
>in favor of downward closures (because in my experience they have been
>very useful, and they are very cheap to implement). But I remain
>unconvinced about full closures (because they seem less commonly needed,
>and they are substantially more expensive to implement -- although your
>benchmark shows that in at least one case, the run-time cost is a myth).
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.
>And the only serious example anybody posted was Ackermann's function,
>which is useful in explaining how full closures work, but doesn't
>exactly make me want to use them every day.
Well, the classic application of full closures in Scheme is OOP.
Scheme has far too many OOP dialects, because it is extremely easy for
everyone to implement their own OOP system using closures.
The classic *idiom* using closures is simulating modules:
(define export1) ; top level placeholder declarations
(define export2)
(let ( <<local declarations >> )
(set! export1 (lambda <<args>> <<body>>))
(set! export2 (lambda <<args>> <<body>>)))
The exported functions have access to the local declarations.
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.
--
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
next prev parent reply other threads:[~1996-07-29 0:00 UTC|newest]
Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-07-02 0:00 Q: access to subprogram tmoran
1996-07-02 0:00 ` Robert A Duff
1996-07-02 0:00 ` Robert Dewar
1996-07-03 0:00 ` Fergus Henderson
1996-07-03 0:00 ` Robert A Duff
1996-07-03 0:00 ` Adam Beneschan
1996-07-03 0:00 ` Robert A Duff
1996-07-03 0:00 ` Robert Dewar
1996-07-09 0:00 ` Thomas Wolff
1996-07-03 0:00 ` Robert Dewar
1996-07-03 0:00 ` Jon S Anthony
1996-07-03 0:00 ` Robert A Duff
1996-07-08 0:00 ` Norman H. Cohen
1996-07-09 0:00 ` Robert A Duff
1996-07-03 0:00 ` Robert Dewar
1996-07-03 0:00 ` Mark A Biggar
1996-07-03 0:00 ` Robert Dewar
1996-07-06 0:00 ` Robert A Duff
1996-07-08 0:00 ` Norman H. Cohen
1996-07-08 0:00 ` Robert Dewar
1996-07-11 0:00 ` Robert A Duff
1996-07-12 0:00 ` Robert A Duff
1996-07-14 0:00 ` Norman H. Cohen
1996-07-03 0:00 ` Robert A Duff
1996-07-03 0:00 ` Robert Dewar
1996-07-09 0:00 ` Thomas Wolff
1996-07-09 0:00 ` Robert Dewar
1996-07-10 0:00 ` Robert A Duff
1996-07-10 0:00 ` Richard A. O'Keefe
1996-07-10 0:00 ` Robert A Duff
1996-07-10 0:00 ` Thomas Wolff
1996-07-10 0:00 ` Robert A Duff
1996-07-10 0:00 ` Robert Dewar
1996-07-10 0:00 ` Robert Dewar
1996-07-19 0:00 ` Brian Rogoff
1996-07-22 0:00 ` Richard A. O'Keefe
1996-07-23 0:00 ` Brian Rogoff
1996-07-23 0:00 ` Robert A Duff
1996-07-26 0:00 ` Brian Rogoff
1996-07-28 0:00 ` Robert A Duff
1996-07-22 0:00 ` Brian Rogoff
1996-07-23 0:00 ` Robert A Duff
1996-07-24 0:00 ` Richard A. O'Keefe
1996-07-26 0:00 ` Ken Garlington
1996-07-30 0:00 ` Richard A. O'Keefe
1996-07-24 0:00 ` Brian Rogoff
1996-07-26 0:00 ` Robert A Duff
1996-07-30 0:00 ` Brian Rogoff
1996-07-24 0:00 ` Brian Rogoff
1996-07-26 0:00 ` Richard A. O'Keefe
1996-07-28 0:00 ` Fergus Henderson
1996-07-28 0:00 ` Robert A Duff
1996-07-29 0:00 ` Richard A. O'Keefe [this message]
1996-07-29 0:00 ` Robert A Duff
1996-07-29 0:00 ` Richard A. O'Keefe
1996-07-30 0:00 ` Jon S Anthony
1996-07-05 0:00 ` Jon S Anthony
1996-07-06 0:00 ` Robert Dewar
1996-07-06 0:00 ` Robert A Duff
1996-07-06 0:00 ` Robert Dewar
1996-07-08 0:00 ` Robert A Duff
1996-07-08 0:00 ` Richard A. O'Keefe
1996-07-08 0:00 ` Robert A Duff
1996-07-08 0:00 ` Robert Dewar
1996-07-08 0:00 ` Robert Dewar
1996-07-10 0:00 ` Richard A. O'Keefe
1996-07-10 0:00 ` Robert Dewar
1996-07-19 0:00 ` Richard A. O'Keefe
1996-07-07 0:00 ` Ronald Cole
1996-07-07 0:00 ` Richard Kenner
1996-07-07 0:00 ` Robert Dewar
1996-07-07 0:00 ` Richard Kenner
1996-07-07 0:00 ` Robert Dewar
1996-07-14 0:00 ` Ronald Cole
1996-07-14 0:00 ` Richard Kenner
1996-07-15 0:00 ` Fergus Henderson
1996-07-15 0:00 ` Robert Dewar
1996-07-17 0:00 ` Fergus Henderson
1996-07-17 0:00 ` Richard Kenner
1996-07-17 0:00 ` Adam Beneschan
1996-07-20 0:00 ` Michael Feldman
1996-07-20 0:00 ` Robert Dewar
1996-07-16 0:00 ` Richard Kenner
1996-07-07 0:00 ` Mark Eichin
1996-07-08 0:00 ` Richard Kenner
1996-07-08 0:00 ` Brian Rogoff
1996-07-11 0:00 ` Norman H. Cohen
1996-07-11 0:00 ` Magnus Kempe
1996-07-11 0:00 ` Robert Dewar
1996-07-09 0:00 ` Jon S Anthony
1996-07-09 0:00 ` Robert Dewar
1996-07-09 0:00 ` Robert Dewar
1996-07-09 0:00 ` Jon S Anthony
1996-07-09 0:00 ` Robert Dewar
1996-07-10 0:00 ` Ronald Cole
1996-07-11 0:00 ` Richard Kenner
1996-07-11 0:00 ` Robert Dewar
1996-07-11 0:00 ` Jon S Anthony
1996-07-11 0:00 ` Jon S Anthony
1996-07-11 0:00 ` Robert Dewar
1996-07-11 0:00 ` Jon S Anthony
1996-07-11 0:00 ` Robert Dewar
1996-07-15 0:00 ` Mark A Biggar
1996-07-15 0:00 ` Robert Dewar
1996-07-11 0:00 ` Tucker Taft
1996-07-17 0:00 ` Brian Rogoff
1996-07-12 0:00 ` Jon S Anthony
1996-07-12 0:00 ` Robert Dewar
1996-07-15 0:00 ` Jon S Anthony
1996-07-15 0:00 ` Robert Dewar
1996-07-12 0:00 ` Brian Rogoff
1996-07-16 0:00 ` Magnus Kempe
1996-07-14 0:00 ` Ronald Cole
1996-07-14 0:00 ` Robert Dewar
1996-07-15 0:00 ` Jon S Anthony
1996-07-15 0:00 ` Robert Dewar
1996-07-16 0:00 ` Brian Rogoff
1996-07-24 0:00 ` Jon S Anthony
1996-07-25 0:00 ` Fergus Henderson
1996-07-25 0:00 ` David Kristola
1996-07-26 0:00 ` Robert A Duff
1996-07-30 0:00 ` Thomas Wolff
1996-07-30 0:00 ` Robert A Duff
1996-07-30 0:00 ` David Kristola
1996-07-26 0:00 ` Robert A Duff
1996-07-26 0:00 ` Fergus Henderson
1996-07-28 0:00 ` Robert A Duff
1996-07-28 0:00 ` Fergus Henderson
1996-07-25 0:00 ` Jon S Anthony
-- strict thread matches above, loose matches on Subject: below --
1996-07-05 0:00 tmoran
1996-07-06 0:00 ` Robert A Duff
1996-07-15 0:00 tmoran
1996-07-15 0:00 ` Robert Dewar
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox