call/cc in lisp
Masoud Pirnazar
(maybe some libraries that provide similar functionality?)
Kent M Pitman
> 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.
Bruce Hoult
<pit...@world.std.com> wrote:
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.
-- Bruce
Per Bothner
> 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.)
Frank Goenninger
Hi Masoud!
"Masoud Pirnazar" <amp.x...@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.
HTH.
Frank
David Sletten
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
David Sletten
Kent M Pitman
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.
http://world.std.com/~pitman/pfaq/unwind-protect-vs-continuations.html
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.
Erik Naggum
> 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.
Rob Warnock
+---------------
| * 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 <rp...@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: aaan...@sgi.com and zedw...@sgi.com aren't for humans ]