"Masoud Pirnazar" <amp.xnos...@apptek.com> writes: > is there an equivalent of the scheme call/cc (continuations) for lisp? > (maybe some libraries that provide similar functionality?)
No. CATCH and THROW are the closest you'll get. Lisp continuations have dynamic, not indefinite extent. And they are not reentrant.
A compatibility library for this would be extremely hard to arrange because it would probably involves transforming ALL relevant code to use Continuation Passing Style (CPS) in order that continuations would become manifestly manipulable objects. Further, in the process of doing this, you'd have to develop a model of what happened to special variables and UNWIND-PROTECT and other dynamic effects. Even Scheme does not have a good theory of how call/cc and unwind-protect interact--they just hide it by not offering unwind-protect and claiming that it is left as an exercise to the user. The truth is that unwind-protect is a mess in the presence of call/cc. And given the choice between the two, I'd pick unwind-protect any day.
> > is there an equivalent of the scheme call/cc (continuations) for lisp? > > (maybe some libraries that provide similar functionality?)
> No. CATCH and THROW are the closest you'll get. Lisp continuations have > dynamic, not indefinite extent. And they are not reentrant.
> A compatibility library for this would be extremely hard to arrange > because > it would probably involves transforming ALL relevant code to use > Continuation > Passing Style (CPS) in order that continuations would become manifestly > manipulable objects. Further, in the process of doing this, you'd have > to > develop a model of what happened to special variables and UNWIND-PROTECT > and other dynamic effects. Even Scheme does not have a good theory of > how call/cc and unwind-protect interact--they just hide it by not > offering > unwind-protect and claiming that it is left as an exercise to the user. > The truth is that unwind-protect is a mess in the presence of call/cc. > And given the choice between the two, I'd pick unwind-protect any day.
All the above about Common Lisp also applies to Dylan, which is in most other semantic respects closer to Scheme than to CL (plus CLOS, of course).
Dylan unifies the concepts of conditions and restarts -- both have calling semantics -- and uses macros to build the high level exception handling facilities on top of conditions/restarts, lexical closures, and escape functions (one-shot continuations that are valid only until the creating environment exits).
The other main use for continuations is to build co-routines. Dylan intends you to use the OS's (or runtime library's) threads package for that. I guess this is probably also the case in Common Lisp.
Kent M Pitman wrote: > Even Scheme does not have a good theory of > how call/cc and unwind-protect interact--they just hide it by not offering > unwind-protect and claiming that it is left as an exercise to the user.
R5RS has 'dynamic-wind' which is a generalizationm of unwind-protect. (It takes an extra parameter whiich is a function called when the body is re-entered.) However, there does appears to be some problems with dynamic-wind, and I understand the definition in R5RS is bad. (I don't know the specifics.)
"Masoud Pirnazar" <amp.xnos...@apptek.com> writes: > is there an equivalent of the scheme call/cc (continuations) for lisp? > (maybe some libraries that provide similar functionality?)
AFAIK the closest thing to what you are looking for (with an explanation of limitations and differences) is given in "On Lisp", by Paul Graham, published by Prentice-Hall, Inc. under ISBN 0-13-030552-9. See chapter 20, Continuations.
It might be difficult to get hold of a copy of this book, though. It was out of print.
Masoud Pirnazar wrote: > is there an equivalent of the scheme call/cc (continuations) for lisp? > (maybe some libraries that provide similar functionality?)
Peter Norvig discusses the issue in chapters 22, 23 of PAIP
Per Bothner <p...@bothner.com> writes: > Kent M Pitman wrote:
> > Even Scheme does not have a good theory of > > how call/cc and unwind-protect interact--they just hide it by not offering > > unwind-protect and claiming that it is left as an exercise to the user.
> R5RS has 'dynamic-wind' which is a generalizationm of unwind-protect. > (It takes an extra parameter whiich is a function called when the > body is re-entered.) However, there does appears to be some problems > with dynamic-wind, and I understand the definition in R5RS is bad. > (I don't know the specifics.)
There was recent discussion of dynamic-wind, and I'm convinced there are some problems with it, but those problems are orthogonal to the issue at hand.
dynamic-wind serves a completely different need than unwind-protect.
Pushed over the edge by having to speak on this complicated issue for the n-millionth time, I've added my position on this to my personal faq so that I can just allude to it in the future.
By the way, the world.std.com server is performing VERY badly of late, so if you pull this up, be very patient. (sigh)
Also, I dashed the article out rather hastily and did not really proofread it well. It may contain typos, etc. I'll fix them later when I have more time. Running spellcheck on stuff containing code is more tedious than I can bear right now. I just wanted to get the basic framework laid out for now.
> R5RS has 'dynamic-wind' which is a generalizationm of unwind-protect.
Kent Pitman has shown that the two mechanisms are orhogonal. I do not buy the line that dynamic-wind can implement unwind-protect properly. Could you show us how it can?
/// -- Why did that stupid George W. Bush turn to Christian fundamentalism to fight Islamic fundamentalism? Why use terms like "crusade", which only invokes fear of a repetition of that disgraceful period of Christianity with its _sustained_ terrorist attacks on Islam? He is _such_ an idiot.
Erik Naggum <e...@naggum.net> wrote: +--------------- | * Per Bothner <p...@bothner.com> | > R5RS has 'dynamic-wind' which is a generalizationm of unwind-protect. | | Kent Pitman has shown that the two mechanisms are orhogonal. I do not | buy the line that dynamic-wind can implement unwind-protect properly. | Could you show us how it can? +---------------
Indeed, the last time this came up (back in May?), I believe I showed in <URL:news:9e00uc$915mi$1@fido.engr.sgi.com> that R5RS "dynamic-wind" specifically *lacks* the ability to emulate UNWIND-PROTECT, since in CL the cleanup form is allowed to THROW (provided it's to a context further up the stack than the target of the current non-local exit, see CLHS 5.2 and 5.3->THROW), whereas in R5RS the "after" form is not:
6.4 Control features ... (dynamic-wind before thunk after) ... The effect of using a captured continuation to enter or exit the dynamic extent of a call to "before" or "after" is undefined.
But even more important was the observation that:
...there is no guarantee anywhere in R5RS that "signalling an error" interacts in any way with dynamic-wind!! At most an implementation is required to "detect and report" certain errors, but it's not required to do this by calling a continuation captured with call/cc in the top-level REPL (albeit that's one "obvious" implementation), and thus it's not required to execute any "after" thunks in any active dynamic-winds.
This means that R5RS call/cc + dynamic-wind are inadequate to implement a portable exception-handling system.
Q.E.D.
-Rob
----- Rob Warnock, 30-3-510 <r...@sgi.com> SGI Network Engineering <http://reality.sgi.com/rpw3/> 1600 Amphitheatre Pkwy. Phone: 650-933-1673 Mountain View, CA 94043 PP-ASEL-IA
[Note: aaanal...@sgi.com and zedwa...@sgi.com aren't for humans ]
