Hi,
is there a de-facto standard implementation of continuations in Common Lisp?
Are there any suggestions how I can make my way to understanding and using continuations?
Andreas
>Hi,
>
>is there a de-facto standard implementation of continuations
>in Common Lisp?
>
>Are there any suggestions how I can make my way to
>understanding and using continuations?
>
>Andreas
Chapter 20 in Paul Graham's "On Lisp" covers continuations. He
discusses how they work in Scheme (where they are part of the standard)
and presents a simple implementation of continuations in Common Lisp.
Paul Graham has licensed all code in his book as non-profit only.
For additional implementations of continuations in Common Lisp, I would
check common-lisp.net (I haven't checked yet). For additional
educational material I would ask in the Scheme newsgroup
(comp.lang.scheme) since those folks likely have more experience with
continuations than we do.
>Chapter 20 in Paul Graham's "On Lisp" covers continuations.
http://paulgraham.com/onlisptext.html
From: Andreas Thiele
Subject: Re: De-facto standard CL implementation of continuations?
Date:
Message-ID: <ddkvk3$l65$04$1@news.t-online.com>
"Eric Lavigne" <············@gmail.com> schrieb im Newsbeitrag
····························@g44g2000cwa.googlegroups.com...
> >Chapter 20 in Paul Graham's "On Lisp" covers continuations.
>
> http://paulgraham.com/onlisptext.html
>
Thanks for your hints.
Graham explains how continuations work and describes a few tiny macros but doesn't present a full
blown 'implemantation'. This would require a code walker which would be beyond the scope of grahams
book as he says.
What I found so far is:
http://common-lisp.net/project/bese/arnesi.html
which contains "cps transformer - an ad-hoc, bug ridden implementation of half of call/cc",
according to the author :)
Perhaps this plus On Lisp is a good starting point.
Are there other suggestions?
Andreas
From: Marco Baringer
Subject: Re: De-facto standard CL implementation of continuations?
Date:
Message-ID: <m24q9t527u.fsf@soma.local>
"Andreas Thiele" <··········@nospam.com> writes:
> What I found so far is:
>
> http://common-lisp.net/project/bese/arnesi.html
>
> which contains "cps transformer - an ad-hoc, bug ridden
> implementation of half of call/cc", according to the author :)
the cps transformer has recently been removed (though i may add it
back it if others are interested in using it) and replaced with an
interpreter. this removed many of the limitations of the transformer
though the qualification "ad-hog, bug ridden implementation of half of
call/cc" still applies. in particular we now support multiple values,
standard method combination and serializing continuations (well, it's
possible, but not yet implemented).
i would strongly suggest grabbing the latest version of arnesi from
the darcs repo and using the interpreter.
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
"Marco Baringer" <··@bese.it> wrote:
> "Andreas Thiele" <··········@nospam.com> writes:
>
>> What I found so far is:
>>
>> http://common-lisp.net/project/bese/arnesi.html
>>
>> which contains "cps transformer - an ad-hoc, bug ridden
>> implementation of half of call/cc", according to the author :)
>
> the cps transformer has recently been removed (though i may add it
> back it if others are interested in using it) and replaced with an
> interpreter. this removed many of the limitations of the transformer
> though the qualification "ad-hog, bug ridden implementation of half of
> call/cc" still applies. in particular we now support multiple values,
> standard method combination and serializing continuations (well, it's
> possible, but not yet implemented).
Serialzing continuations? I would find that *very* useful.
Do you have any thoughts on how this would work?
Aside: can you serialize a Scheme continuation?
Jamie
>
> i would strongly suggest grabbing the latest version of arnesi from
> the darcs repo and using the interpreter.
>
> --
> -Marco
> Ring the bells that still can ring.
> Forget the perfect offering.
> There is a crack in everything.
> That's how the light gets in.
> -Leonard Cohen
"Peter Scott" <·········@gmail.com> wrote:
> In some schemes you can serialize continuations.
>
Could you point to some simplistic example? I cannot visualize how a
serialized continuation would look...
I was hoping I could do good stuff like:
* Write them to streams
* Write to string (therefore send across network)
* Post them on USENET (I paused evaluation *here*, look!)
* Print them out and stick them on the wall :-)
Jamie
Jamie Border wrote:
> Serialzing continuations? I would find that *very* useful.
>
> Do you have any thoughts on how this would work?
>
> Aside: can you serialize a Scheme continuation?
It's not required by the standard, but in many of the
better scheme implementations, you can use read and
write to serialize/deserialize continuations, both
to/from files and strings.
I haven't looked at exactly how it works though; now
that I think about it I'm curious how they avoid garbage
collecting the invocation frames of the procedure calls
involved if they don't maintain a reference to the
continuation. Or maybe they have to serialize the
entire "stack" with a continuation read it back in,
and replace any collected frames. But then mutations
in scoped variables don't get preserved if the frame
is mutated and then reaped before the continuation is
read back, so how.... ?
Bear
On Sat, 13 Aug 2005 23:20:49 +0000, Ray Dillinger wrote:
> It's not required by the standard, but in many of the
> better scheme implementations, you can use read and
> write to serialize/deserialize continuations, both
> to/from files and strings.
>
> I haven't looked at exactly how it works though
Neither have I, but that won't stop me from speculating ;-)
> now that I think about it I'm curious how they avoid garbage
> collecting the invocation frames of the procedure calls
> involved if they don't maintain a reference to the
> continuation.
This, I believe, is orthogonal to serialization.
> Or maybe they have to serialize the
> entire "stack" with a continuation read it back in,
> and replace any collected frames. But then mutations
> in scoped variables don't get preserved if the frame
> is mutated and then reaped before the continuation is
> read back, so how.... ?
There are a few issues going on here. I'm guessing here, but I would say
that compilers that do serialize are just giving you something for free.
When handling your normal everyday continuations there are generally two
methods: i) copy stack on capture, ii) allocate *all* frames in heap
avoiding the stack entirely. When you already have written the code to
copy the stack, it's trivial to write it out to a file. And there is no GC
issue as the stack is self-contained (i.e. all local variables are
contained in the stack and references are stack offsets). Think of it as
writing a C struct to a file and reading it back in (modulo alignment
issues). The fields contain the correct data, so far as correct means what
you serialized. If you mutate a field, exit the program, load the
program and read the serialized struct... you only get the version of the
field (variable) you saved.
All that said, you might run into a problem if you do something like...
(set! *global-var* (call/cc (lambda (k) (save-cont-to-file k)))
Then later reload the system but forget to load the right modules or
define all the top-level variables. Nasal demons, etc. etc.
The stack method is seen as the more difficult method to implement, so
it would be no surprise if the better implementations used it. And while
we're at it... the theory goes, those that use call/cc should pay the
higher price (stack copy method) rather than penalize all procedure calls
(heap). But the "heap is slow" theory has been disputed, and it all
really depends on so many more details that, if you didn't know your
requirements, you could flip a coin and it wouldn't make a bit of
difference which method to pick.
Tim
(message (Hello 'Jamie)
(you :wrote :on '(Sat, 13 Aug 2005 16:32:42 +0000 (UTC)))
(
JB> Serialzing continuations? I would find that *very* useful.
JB> Do you have any thoughts on how this would work?
JB> Aside: can you serialize a Scheme continuation?
it's possible to serialize continuations in Rhino -- implementation of
JavaScript in Java, that is used in Cocoon Java web-application framework as
flow script (because it was hard to implement continuations on Java itself).
afair i've read something they can move sessions with stored continuations
from one server to another (for load-balancing support).
there is also implementation of continuations in Java itself (via secondary
java bytecode interpreter) and they say continuations are serializable there
too, but i didn't find much info on it..
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
From: Marco Baringer
Subject: Re: De-facto standard CL implementation of continuations?
Date:
Message-ID: <m2wtmno60t.fsf@soma.local>
"Jamie Border" <·····@jborder.com> writes:
> Serialzing continuations? I would find that *very* useful.
>
> Do you have any thoughts on how this would work?
since i wrote the interpreter i also got to chose the representation
of the continuations :). every continuation is a list of 1) lists, 2)
symbols, 3) 'simple' (non-circular) clos objects and 4) user
data, these are all easily serializable.
the real problem is how these interact with lexical variables:
; loading system definition from /Users/mb/lisp/systems/arnesi.asd into
; #<Package "ASDF67">
; registering #<SYSTEM :ARNESI #x64DA11E> as ARNESI
; registering #<SYSTEM :ARNESI.TEST #x64E98B6> as ARNESI.TEST
; registering #<SYSTEM :ARNESI.CL-PPCRE-EXTRAS #x64E2DA6> as
; ARNESI.CL-PPCRE-EXTRAS
CL-USER>
ARNESI> (defvar *cont*)
*CONT*
;; create a continuation which wraps a lexical variable outside the
;; context of the continuation.
ARNESI> (let ((x 'whatever))
(with-call/cc
(setf x (call/cc (lambda (k)
(setf *cont* k))))
(format t "Afterwards x is ~D.~%" x))
(defun foo () x))
FOO
;; proof that our continuations are just lists
ARNESI> *cont*
(K-FOR-LOCAL-LEXICAL-SETQ X ((:LEXICAL-LET X #<CCL:COMPILED-LEXICAL-CLOSURE #x6587076> #<CCL:COMPILED-LEXICAL-CLOSURE #x658705E>)) (K-FOR-EVALUATE-PROGN/CC (#<FREE-APPLICATION-FORM (FORMAT T "Afterwards x is ~D.~%" X) #x658B866>) ((:LEXICAL-LET X #<CCL:COMPILED-LEXICAL-CLOSURE #x6587076> #<CCL:COMPILED-LEXICAL-CLOSURE #x658705E>)) (TOPLEVEL-K)))
ARNESI> (foo)
WHATEVER
;; NB: Continuing our continuation does not redefine FOO. our
;; continuations are limited to the with-call/cc form.
ARNESI> (kall *cont* 'fuzzball)
Afterwards x is FUZZBALL.
NIL
;; but we have still managed to change the value of the closed over
;; variable X
ARNESI> (foo)
FUZZBALL
ARNESI> (kall *cont* 'gibbly-gook)
Afterwards x is GIBBLY-GOOK.
NIL
ARNESI> (foo)
GIBBLY-GOOK
ARNESI>
However, were you to save and the restore *CONT* you'd find that 1)
the value of X is not saved (as far as the closure FOO is concerned)
and 2) calling *cont* (in a new image) does not affect X. What we end
up doing is just not allowing modifying lexical variables in
continuations which need to be serialized (this limitiation isn't as
bad as it seems (though it does suck)).
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
From: Andreas Thiele
Subject: Re: De-facto standard CL implementation of continuations?
Date:
Message-ID: <ddl4k6$jo4$00$1@news.t-online.com>
Thanks for your quick response. I'll certainly take a look.
Andreas
On 2005-08-13, Marco Baringer <··@bese.it> wrote:
> the cps transformer has recently been removed (though i may add it
> back it if others are interested in using it) and replaced with an
> interpreter. this removed many of the limitations of the transformer
> though the qualification "ad-hog, bug ridden implementation of half of
> call/cc" still applies. in particular we now support multiple values,
> standard method combination and serializing continuations (well, it's
> possible, but not yet implemented).
I'm curious about the performance impact of this - how much of the code called
from within the call/cc wrapper remains natively compiled and how much needs to
be interpreted? From a brief look it appeared as if the interpreter didn't need
to do much except call existing compiled closures.
-Klaus
Eric Lavigne wrote:
> >Hi,
> >
> >is there a de-facto standard implementation of continuations
> >in Common Lisp?
> >
> >Are there any suggestions how I can make my way to
> >understanding and using continuations?
> >
> >Andreas
>
> Chapter 20 in Paul Graham's "On Lisp" covers continuations. He
> discusses how they work in Scheme (where they are part of the standard)
> and presents a simple implementation of continuations in Common Lisp.
> Paul Graham has licensed all code in his book as non-profit only.
Unfortunatelly, the code in this chapter is not quite ANSI CL
compatible. One has to find a way to make a lexical global variable.
In SBCL and CMUCL one can use the deprecated set function:
(set 'some-var 2)
>
> For additional implementations of continuations in Common Lisp, I would
> check common-lisp.net (I haven't checked yet). For additional
> educational material I would ask in the Scheme newsgroup
> (comp.lang.scheme) since those folks likely have more experience with
> continuations than we do
Also Screamer[1] appears to have a CPS transformer. I haven't looked
at it, though, so don't know how it compares with arnesi.
[1] http://www.cliki.net/Screamer
"ivant" <········@gmail.com> writes:
> Unfortunatelly, the code in this chapter is not quite ANSI CL
> compatible. One has to find a way to make a lexical global variable.
> In SBCL and CMUCL one can use the deprecated set function:
>
> (set 'some-var 2)
Or you can fake it portably without invoking undefined behavior:
(defvar *some-var* 2)
(define-symbol-macro some-var (symbol-value '*some-var*))
And now you have some-var, which behaves like a global lexical.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
+---------------
| "ivant" <········@gmail.com> writes:
| > Unfortunatelly, the code in this chapter is not quite ANSI CL
| > compatible. One has to find a way to make a lexical global variable.
| > In SBCL and CMUCL one can use the deprecated set function:
| > (set 'some-var 2)
|
| Or you can fake it portably without invoking undefined behavior:
| (defvar *some-var* 2)
| (define-symbol-macro some-var (symbol-value '*some-var*))
| And now you have some-var, which behaves like a global lexical.
+---------------
;;; DEFLEX -- Define "global lexical variables", that is, top-level
;;; variables (convenient when debugging) that are lexical in scope.
;;; Thanks to the denizens of the "comp.lang.lisp" newsgroup for many
;;; useful discussions (and flames!) on this topic, and for the suggestion
;;; for the simple and efficient (albeit inelegant) "shadow" variable
;;; approach used here.
;;;
;;; 2005-06-12 -- Package bugfix courtesy Adam Warner <····@consulting.net.nz>
;;;
(defmacro deflex (var val &optional (doc nil docp))
"Define a top level (global) lexical VAR with initial value VAL,
which is assigned unconditionally as with DEFPARAMETER. If a DOC
string is provided, it is attached to both the name |VAR| and the
name *STORAGE-FOR-DEFLEX-VAR-|VAR|* as a documentation string of
kind 'VARIABLE. The new VAR will have lexical scope and thus may be
shadowed by LET bindings without affecting its dynamic (global) value."
(let* ((s0 (symbol-name '#:*storage-for-deflex-var-))
(s1 (symbol-name var))
(s2 (symbol-name '#:*))
(s3 (symbol-package var)) ; BUGFIX [see above]
(backing-var (intern (concatenate 'string s0 s1 s2) s3)))
;; Note: The DEFINE-SYMBOL-MACRO must be the last thing we do so
;; that the value of the form is the symbol VAR.
(if docp
`(progn
(defparameter ,backing-var ,val ,doc)
(setf (documentation ',var 'variable) ,doc)
(define-symbol-macro ,var ,backing-var))
`(progn
(defparameter ,backing-var ,val)
(define-symbol-macro ,var ,backing-var)))))
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> (defvar *some-var* 2)
> (define-symbol-macro some-var (symbol-value '*some-var*))
>
> And now you have some-var, which behaves like a global lexical.
If it'sa global lexical, non dynamic (special), why do you name it with stars?
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
Pascal Bourguignon <····@mouse-potato.com> writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > (defvar *some-var* 2)
> > (define-symbol-macro some-var (symbol-value '*some-var*))
> >
> > And now you have some-var, which behaves like a global lexical.
>
> If it'sa global lexical, non dynamic (special), why do you name it with stars?
Read, Pascal! There are two things there, one global special named
*some-var*, and one symbol macro named some-var. It's the latter that
behaves like a global lexical.
I could have posted a deflexical macro, but I didn't want to obscure
the simple mechanics of how it would work with the machinery of the
macro. When experienced lispers who ought to be able to read two
lines of simple code come and post misleading responses, that undoes
all the intended newbie-friendliness.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
+---------------
| Pascal Bourguignon <····@mouse-potato.com> writes:
|
| > ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
| > > (defvar *some-var* 2)
| > > (define-symbol-macro some-var (symbol-value '*some-var*))
| > >
| > > And now you have some-var, which behaves like a global lexical.
| >
| > If it'sa global lexical, non dynamic (special), why do you name it with stars?
|
| Read, Pascal! There are two things there, one global special named
| *some-var*, and one symbol macro named some-var. It's the latter that
| behaves like a global lexical.
|
| I could have posted a deflexical macro, but I didn't want to obscure
| the simple mechanics of how it would work with the machinery of the
| macro. When experienced lispers who ought to be able to read two
| lines of simple code come and post misleading responses, that undoes
| all the intended newbie-friendliness.
+---------------
Oops. Sorry. I too posted before reading closely enough. (*blush*)
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
>> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>> > (defvar *some-var* 2)
>> > (define-symbol-macro some-var (symbol-value '*some-var*))
>> >
>> > And now you have some-var, which behaves like a global lexical.
>>
>> If it'sa global lexical, non dynamic (special), why do you name it with stars?
>
> Read, Pascal! There are two things there, one global special named
> *some-var*, and one symbol macro named some-var. It's the latter that
> behaves like a global lexical.
Indeed. Time for me to switch off.
> I could have posted a deflexical macro, but I didn't want to obscure
> the simple mechanics of how it would work with the machinery of the
> macro. When experienced lispers who ought to be able to read two
> lines of simple code come and post misleading responses, that undoes
> all the intended newbie-friendliness.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
Pascal Bourguignon <····@mouse-potato.com> wrote:
+---------------
| ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
| > (defvar *some-var* 2)
| > (define-symbol-macro some-var (symbol-value '*some-var*))
| >
| > And now you have some-var, which behaves like a global lexical.
|
| If it'sa global lexical, non dynamic (special), why do you
| name it with stars?
+---------------
One shouldn't, of course. And when I'm using my DEFLEX macro
[posted separately], I don't:
> (deflex a 34)
A
> (defun value-of-global-a () a)
VALUE-OF-GLOBAL-A
> (let ((a 53))
(list a (value-of-global-a)))
(53 34)
>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Lars Brinkhoff
Subject: Re: De-facto standard CL implementation of continuations?
Date:
Message-ID: <85acivwu91.fsf@junk.nocrew.org>
Ingvar <······@hexapodia.net> writes:
> * (defvar *some-var* 2)
> * (define-symbol-macro some-var (symbol-value '*some-var*))
I don't understand the difference between having the macro expand to
(symbol-value '*some-var*) versus just *some-var*. Earlier
comp.lang.lisp threads about this used the plain symbol, but later
versions have switched to symbol-value. I would have thought them to
be equivalent. What am I missing?
Ingvar wrote:
> Lars Brinkhoff <·········@nocrew.org> writes:
>
> > Ingvar <······@hexapodia.net> writes:
> > > * (defvar *some-var* 2)
> > > * (define-symbol-macro some-var (symbol-value '*some-var*))
> >
> > I don't understand the difference between having the macro expand to
> > (symbol-value '*some-var*) versus just *some-var*. Earlier
> > comp.lang.lisp threads about this used the plain symbol, but later
> > versions have switched to symbol-value. I would have thought them to
> > be equivalent. What am I missing?
>
> I dunno, I copied-and-pasted the handed-out solution, rather than
> implement from scratch. I would, probably, have used the plain
> unadorned symbol, were I to do it. I might well be missing something,
> though.
Isn't in necessary in case someone puts a lexical variable in the
program with the name *some-var*? (I'm not sure)
From: Lars Brinkhoff
Subject: Re: De-facto standard CL implementation of continuations?
Date:
Message-ID: <85k6hyuvn4.fsf@junk.nocrew.org>
"Rob Thorpe" <·············@antenova.com> writes:
>> Lars Brinkhoff <·········@nocrew.org> writes:
>>> Ingvar <······@hexapodia.net> writes:
>>>> * (defvar *some-var* 2)
>>>> * (define-symbol-macro some-var (symbol-value '*some-var*))
>>> I don't understand the difference between having the macro expand to
>>> (symbol-value '*some-var*) versus just *some-var*.
> Isn't in necessary in case someone puts a lexical variable in the
> program with the name *some-var*? (I'm not sure)
Yes, that seems like a good reason. Thanks.
In article <··············@junk.nocrew.org>,
Lars Brinkhoff <·········@nocrew.org> wrote:
> "Rob Thorpe" <·············@antenova.com> writes:
> >> Lars Brinkhoff <·········@nocrew.org> writes:
> >>> Ingvar <······@hexapodia.net> writes:
> >>>> * (defvar *some-var* 2)
> >>>> * (define-symbol-macro some-var (symbol-value '*some-var*))
> >>> I don't understand the difference between having the macro expand to
> >>> (symbol-value '*some-var*) versus just *some-var*.
> > Isn't in necessary in case someone puts a lexical variable in the
> > program with the name *some-var*? (I'm not sure)
>
> Yes, that seems like a good reason. Thanks.
Once *some-var* has been defvar'd it is no longer possible to create a
lexical variable with that name. So symbol-value is not necessary.
rg
From: Pascal Costanza
Subject: Re: De-facto standard CL implementation of continuations?
Date:
Message-ID: <3nrcomF2vmp6U1@individual.net>
ivant wrote:
>>Chapter 20 in Paul Graham's "On Lisp" covers continuations. He
>>discusses how they work in Scheme (where they are part of the standard)
>>and presents a simple implementation of continuations in Common Lisp.
>>Paul Graham has licensed all code in his book as non-profit only.
>
> Unfortunatelly, the code in this chapter is not quite ANSI CL
> compatible. One has to find a way to make a lexical global variable.
That's trivial:
(defmacro defglobal (name value)
(let ((dname (gensym)))
`(progn
(defparameter ,dname ,value)
(define-symbol-macro ,name ,dname)
',name)))
That's because symbol macros are lexically scoped.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++