Re: continuations (was Re: error() or nil, 'error msg')

[Coda Highland <chighland@...>]

On Wed, Sep 24, 2014 at 1:35 PM, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Tom N Harris once stated:
>> On Wednesday, September 24, 2014 12:55:15 PM Sean Conner wrote:
>> >   How is that any different from BASIC's "on error goto ... " statement?
>> >
>> >   Also, you have the ability to jump to labels in an outer function, but it
>> > involves pcall()/error() ...
>>
>> I think the biggest problem with "on error" is that it's an implicit goto.
>> Jumps should be explicit, and the labels within lexical scope.
>>
>> The pcall solution does allow us to jump back to a continuation point, but
>> it's all-or-nothing where multiple error handlers could trample on each other
>> unless there is careful discipline. Not that there's anything wrong with
>> careful discipline of course. Also, error() jumps are dynamically scoped.
>>
>> As Roberto says, a broader goto would be a form of continuation. On the other
>> hand, aren't most use cases for continuations also handled by coroutines? The
>> one that comes to my mind is futures. In fact, right now the way I see this
>> being implemented is by hoisting the function into an implicit coroutine. Then
>> what happens if it's part of an explicit coroutine?
>
>   To my understanding, a "continuation" is the state of a program at a given
> time.  Take a "continuation", let the program run a bit, then resume the
> "continuation" and the state at the time you took the continuation
> (including variables) is restored.  What Roberto mentioned is what you get
> with C's setjmp()/longjmp()---yes, it restores *some* state (mostly CPU
> registers and the call stack) but not everything.
>
>   -spc

Specifically a continuation refers to a program's "control state" or
"execution context" (the specific jargon depends on who you talk to)
-- which, for the most part, is just the call stack, instruction
pointer, and local variables.

If a continuation included the global state of the program, then
executing a continuation would undo whatever processes you ran between
creating the continuation and invoking it, which would be limited in
its usefulness. Sure, it would be nice to unwind things in an
exceptional state, but exceptions aren't the only use of
continuations. The "yield" statement in a coroutine creates a
continuation -- how useful would a coroutine be if invoking it a
second time wiped out everything you'd done since the first
invocation?

/s/ Adam