[gambit-list] Efficient support for delimited continuations?
Chris Newcombe
c_r_newcombe at hotmail.com
Wed Dec 21 23:23:33 EST 2005
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.html)
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 at iro.umontreal.ca>
To: "Newcombe, Chris" <cnewcom at amazon.com>
Cc: <gambit-list at 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 at iro.umontreal.ca
http://mailman.iro.umontreal.ca/mailman/listinfo/gambit-list
More information about the Gambit-list
mailing list