lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


on 8/21/07 5:21 PM, David Given at dg@cowlark.com wrote:

> Doesn't this mean that when the closure returns, it'll abandon the dynamic
> chain containing the event loop and replace it with a clone of the dynamic
> chain that called the setup code? Which means you end up with no event loop?
> Of course, for this situation to occur at all, then the returning setup code
> must eventually arrive at a call to the event loop, which means that the
> cloned dynamic chain will arrive at the same call, and... I think my head
> hurts!

Yes. When the closure returns through the continuation, you will lose the
current dynamic context and be back in the old dynamic context unless you
also have taken action to save the current context.

I'm not advocating that Lua do this. If Lua had non-local returns, I think
the Dylan answer of "it's an error to do that" is perfectly fine.

I think it's perfectly in keeping with Scheme's generally pure character
that it does exactly what the spec says it does no matter how mind-boggling
that answer is. A continuation is the reification of the call stack. When
the spec says that if you call a continuation, it returns from the call to
call/cc then that's what it does and the consequences all more or less
follow.

The world needs design points like Scheme to show what is possible. It also
needs efforts that pull back from the extremes like Lua.

Mark

P.S. Translating into Lua syntax...

    function call_cc( fn, ... )

Calls fn passing it an exit function and any extra arguments. (I can't
remember whether Scheme's call/cc can take extra arguments, but my example
can...) The results of call_cc are either the results from this call to fn
or the results of calling the exit function passed to fn.

--[[ So far so good. We've just defined a way of creating a non-local exit.
This has issues with how it interacts with pcall, but we will ignore those
for now. ]]

Additional calls to the exit function -- e.g., through storing it in a table
-- result in additional returns from call_cc reinstating the dynamic context
in which call_cc was invoked. In other words, the exit function always does
the same thing no matter where you call it from.