[Chicken-users] Continuations
Okay. Let's see if I've got this straight. A continuation is a capture of your location in a program, and its pending operations to return a result. In other languages, this is often represented by the stack. When a continuation is captured, the current state of the stack is captured and can be restored later. The value of variables within the scope of the continuation are not captured: if variables are initialized within a lexical context, a continuation of that context is captured, the values of those variables are altered, and the continuation is restored, the variables will not reset to their original values. In chicken, capturing a continuation is cheap, because you need only take a pointer to a set of data, and register that with the GC. In most other scheme implementations, escpecially those with a stronger focus on C interop, capturing a continuation is expensive, because you need to copy the entire program stack. Did I get anything wrong or miss anything? ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Continuations
Josh Barrett scripsit: > A continuation is a capture of your location in a program, and its pending > operations to return a result. In other languages, this is often > represented by the stack. > > When a continuation is captured, the current state of the stack is captured > and can be restored later. So far so good. > The value of variables within the scope of the continuation are not > captured: if variables are initialized within a lexical context, a > continuation of that context is captured, the values of those variables are > altered, and the continuation is restored, the variables will not reset to > their original values. No, this is not true. The local variables are also on the stack and are captured along with the return addresses. Variables that are above the point where the continuation was captured cannot be restored if they have been changed. > In chicken, capturing a continuation is cheap, because you need only take a > pointer to a set of data, and register that with the GC. In most other > scheme implementations, escpecially those with a stronger focus on C > interop, capturing a continuation is expensive, because you need to copy > the entire program stack. There are ways to make it cheaper, but basically yes. In Chicken, you pay for cheap continuations by occasionally paying much more for ordinary procedure calls (those that fill the C stack and trigger minor garbage collections). In other systems, programs that don't capture continuations don't pay for them. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org Is not a patron, my Lord [Chesterfield], one who looks with unconcern on a man struggling for life in the water, and when he has reached ground encumbers him with help?--Samuel Johnson ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Continuations
Thanks John. That does still leave me with one question: >Variables that are above >the point where the continuation was captured cannot be restored if they have been changed. This seems to imply that the state of variables in the scope the continuation was captured are restored with the continuation, but the state of variables in scopes higher up the stack are not. But that doesn't sound right. If the continuation is copying the entire stack, than every single lexical variable would have its state restored when the continuation was restored, all the way up to toplevel. So if that wasn't what you meant, than what did you mean? On Sat, Jul 16, 2016, 21:40 John Cowan wrote: > Josh Barrett scripsit: > > > A continuation is a capture of your location in a program, and its > pending > > operations to return a result. In other languages, this is often > > represented by the stack. > > > > When a continuation is captured, the current state of the stack is > captured > > and can be restored later. > > So far so good. > > > The value of variables within the scope of the continuation are not > > captured: if variables are initialized within a lexical context, a > > continuation of that context is captured, the values of those variables > are > > altered, and the continuation is restored, the variables will not reset > to > > their original values. > > No, this is not true. The local variables are also on the stack and > are captured along with the return addresses. Variables that are above > the point where the continuation was captured cannot be restored if they > have been changed. > > > In chicken, capturing a continuation is cheap, because you need only > take a > > pointer to a set of data, and register that with the GC. In most other > > scheme implementations, escpecially those with a stronger focus on C > > interop, capturing a continuation is expensive, because you need to copy > > the entire program stack. > > There are ways to make it cheaper, but basically yes. In Chicken, you pay > for cheap continuations by occasionally paying much more for ordinary > procedure calls (those that fill the C stack and trigger minor garbage > collections). In other systems, programs that don't capture continuations > don't pay for them. > > -- > John Cowan http://www.ccil.org/~cowanco...@ccil.org > Is not a patron, my Lord [Chesterfield], one who looks with unconcern > on a man struggling for life in the water, and when he has reached ground > encumbers him with help?--Samuel Johnson > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Continuations
Josh Barrett scripsit: > This seems to imply that the state of variables in the scope the > continuation was captured are restored with the continuation, but the state > of variables in scopes higher up the stack are not. But that doesn't sound > right. If the continuation is copying the entire stack, than every single > lexical variable would have its state restored when the continuation was > restored, all the way up to toplevel. Sorry, you're right and I was wrong, of course. However, truly global variables are not affected by restoring a captured continuation. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org LEAR: Dost thou call me fool, boy? FOOL: All thy other titles thou hast given away: That thou wast born with. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Continuations in C
Hi, I just ran across this and thought it might be useful/interesting for Chicken: From http://luajit.luaforge.net/coco.html: "Coco is a small extension to get True C Coroutine semantics for Lua 5.1. True C coroutine semantics mean you can yield from a coroutine across a C call boundary and resume back to it. Coco allows you to use a dedicated C stack for each coroutine. Resuming and yielding to/from a coroutine automatically switches C stacks, too. In particular you can now: * Yield across all metamethods (not advised for __gc). * Yield across iterator functions (for x in func do). * Yield across callbacks (table.foreach(), dofile(), ...). * Yield across protected callbacks (pcall(), xpcall(), ...). * Yield from C functions and resume back to them. " I have been thinking lately about how to do continuations including the C stack lately; this may be relevant cheers, Daniel ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Continuations in C
On 9/9/05, Daniel B. Faken <[EMAIL PROTECTED]> wrote: > Hi, > > I just ran across this and thought it might be useful/interesting for > Chicken: > From http://luajit.luaforge.net/coco.html: > "Coco is a small extension to get True C Coroutine semantics for Lua 5.1. > Yes this is clever. I thought about using makecontext/setcontext (patching setjmp isn't that nice, really) myself a while ago. Another nice property of this would be that C frames have dynamic extent (they could be garbage collected). Perhaps I find some time to dig deeper into this... cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Continuations in C
Daniel B. Faken wrote: > I have been thinking lately about how to do continuations including the C > stack lately; this may be relevant You might be interested also in checking out the various designs for Stackless Python that Christian Tismer has been through over the years. Several of those support capture of C frames. Tony ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Continuations in C
On Fri, 9 Sep 2005, felix winkelmann wrote: > On 9/9/05, Daniel B. Faken <[EMAIL PROTECTED]> wrote: > > From http://luajit.luaforge.net/coco.html: > > "Coco is a small extension to get True C Coroutine semantics for Lua 5.1. > > > > Yes this is clever. I thought about using makecontext/setcontext > (patching setjmp > isn't that nice, really) myself a while ago. Another nice property of this > would be that C frames have dynamic extent (they could be garbage > collected). Actually I just noticed that, according to the manual, Chicken already kind of supports the "Coroutines in C" idea: "When multiple threads are running concurrently, and control switches from one thread to another, then the continuation of the current thread is captured and saved. Any pending C stack frame still active from a callback will remain on the stack until the threads is re-activated again." [and, since CHICKEN_yield() is just a callback to (thread-yield!), this should work from C] -- right? I have NOT tried this yet! I guess in this sense Chicken has something like Lua's "One-shot continuations", for C. [though I should include the qualifications in the manual: the continuation (ha) of the above quote is: "This means that in a multithreading situation, when C callbacks are involved, the available nursery space can be smaller than expected. So doing many nested Scheme->C->Scheme calls can reduce the available memory up to the point of thrashing. It is advisable to have only a single thread with pending C stack-frames at any given time."] - Daniel ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Continuations, control flow, and F-operator
... So, how does F-operator even exist? It's an egg that implements delimited continuations, that much I know, but HOW? IIRC, it's only possible to implement delimited continuations in pure scheme if all control flow is implemented in continuations. So is that what chicken does? I mean, I know call/cc is fast in chicken, but is it that fast, or is F-operator using some chicken specific implementation that I don't know about? ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Continuations, control flow, and F-operator
Josh Barrett scripsit: > I mean, I know call/cc is fast in chicken, but is it that fast, or is > F-operator using some chicken specific implementation that I don't know > about? No, it isn't. Calling an escape procedure from call/cc is as fast in Chicken as calling a "normal" procedure (which is to say somewhat slower than in comparable Schemes like Gambit), so Oleg Kiselyov's portable implementation works well. There are only a few Chicken-specific touches, as you can see by loading the code with "chicken-install -r F-operator". -- John Cowan http://www.ccil.org/~cowanco...@ccil.org By Elbereth and Luthien the Fair, you shall have neither the Ring nor me! --Frodo ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Continuations, control flow, and F-operator
Thanks John, that helped a lot. On Sun, Dec 13, 2015, 23:56 John Cowan wrote: > Josh Barrett scripsit: > > > I mean, I know call/cc is fast in chicken, but is it that fast, or is > > F-operator using some chicken specific implementation that I don't know > > about? > > No, it isn't. Calling an escape procedure from call/cc is as fast in > Chicken as calling a "normal" procedure (which is to say somewhat slower > than in comparable Schemes like Gambit), so Oleg Kiselyov's portable > implementation works well. There are only a few Chicken-specific touches, > as you can see by loading the code with "chicken-install -r F-operator". > > -- > John Cowan http://www.ccil.org/~cowanco...@ccil.org > By Elbereth and Luthien the Fair, you shall have neither the Ring nor me! > --Frodo > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
