Marc,
Does (or will) Gambit v4 have native support for shift/reset or splitter/abort/call/pc? And if so, can the resulting partial continuations be serialized?
I read your paper on 'A Better API for First-Class Continuations" (http://repository.readscheme.org/ftp/papers/sw2001/feeley.pdf), and I see that Gambit v4 does have continuation-graft. But that paper doesn't mention partial continuations.
Rationale: I am eager to make use of Oleg Kiselyov's 'Zipper In Scheme': http://okmij.org/ftp/Scheme/zipper-in-scheme.txt
Interestingly, at the end of that article, Oleg says "It doesn't matter which particular delimited continuation operator (shift, control, shift0, splitter, cupto, etc) is supported -- all of them are equally expressible", and cites a paper by Chung-chieh Shan which I haven't read yet. However, Christian Queinnec seems to make a good case that his own splitter operator is less dangerous/confusing than shift/reset when nested: http://www-spi.lip6.fr/~queinnec/PDF/contlib.pdf
There's a discussion thread here: http://lambda-the-ultimate.org/node/view/606
Thanks,
Chris
Afficher les réponses par date
On 21-Dec-05, at 8:35 PM, Newcombe, Chris wrote:
Marc,
Does (or will) Gambit v4 have native support for shift/reset or splitter/abort/call/pc? And if so, can the resulting partial continuations be serialized?
The short answer is "no". On the other hand, I don't think it would be too hard to support such control constructs.
Let me reply with a question of my own... why do you need these control operators to be natively supported? You can implement them on top of call/cc fairly easily. Are you worried (obsessed?) with performance?
Marc
Yes, performance is a concern -- it might be the difference between making significant use of zipper (very elegant, many nice properties) or using a more imperative/mutating api. Of course, this is extreme premature optimization as I am only speculating at this point :)
Also I was wondering whether delimited continuations could be serialized more compactly/quickly, as (under the interpreter) only a subtree of the abstract syntax tree (and any state reachable from that subtree) would need to be captured, right? Depending on the size & complexity of an application, that might be a big win when managing really large numbers of concurrent sessions via continuations -- when storing them in client cookies or a database.
An article by Chris Double (http://www.double.co.nz/scheme/partial-continuations/partial-continuations.h...) suggests that such applications really want to use delimited continuations for inherent structual reasons, and that might make performance important again.
Finally, more compact/faster serialization would definitely be a win for distributed applications that make significant use of process migration via your 'goto' operator, or Termite's 'migrate'.
Again, this is only speculation/musing.
Thanks,
Chris
ps. BTW, I couldn't find continuation-graft mentioned in the beta 15 manual, even under the not-yet-documented section (I grepped the source to confirm it is present). Is that intentional?
----- Original Message ----- From: "Marc Feeley" feeley@iro.umontreal.ca To: "Newcombe, Chris" cnewcom@amazon.com Cc: gambit-list@iro.umontreal.ca Sent: Wednesday, December 21, 2005 7:17 PM Subject: Re: [gambit-list] Efficient support for delimited continuations?
On 21-Dec-05, at 8:35 PM, Newcombe, Chris wrote:
Marc,
Does (or will) Gambit v4 have native support for shift/reset or splitter/abort/call/pc? And if so, can the resulting partial continuations be serialized?
The short answer is "no". On the other hand, I don't think it would be too hard to support such control constructs.
Let me reply with a question of my own... why do you need these control operators to be natively supported? You can implement them on top of call/cc fairly easily. Are you worried (obsessed?) with performance?
Marc
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca http://mailman.iro.umontreal.ca/mailman/listinfo/gambit-list
-
Chris Newcombe -
Marc Feeley -
Newcombe, Chris