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

[Sean Conner <sean@...>]

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