Re: to-be-closed: the case for terminating exceptions

[Sean Conner <sean@...>]

It was thus said that the Great John Belmonte once stated:
> *The ability to have __close() suppress an exception is useful* -- more so
> than I thought.
> 
> I'll leave it to Roberto to judge whether this is practical, but as far as
> API, I think it would be:
> 
> "If __close() returns the specific value `false`, then the exception is
> terminated, and execution continues normally, following the exited scope
> (after __close of remaining to-be-closed variables)."  Since existing
> __close() instances are likely to return nothing (`nil`), this behavior is
> backwards-compatible.
> 
> Some example use cases follow.  Of course, pcall() is always a crude
> replacement, but the presumption is that maintaining return/break/goto
> within the code block, and avoiding multiple levels of nested lambdas, is
> highly desirable.

  Why is pcall() a crude replacement?  I'm using it just fine.  Can you give
an example of where it's a problem?  Or is it just the idea of possible
overhead?

> As to-be-closed stands, with no way to terminate exceptions, the next
> installment of  "Structured concurrency and Lua" may be the end of the road
> for now.  It will introduce cancel scopes, but explain that the nursery
> implementation is incomplete, and cancel scopes aren't implemented at all
> -- pending some solution to terminating exceptions.

  I get the feeling that you are trying to force the Python implementation
details of Trio into Lua instead of trying to work with Lua as Lua, but I
don't know enough about this to make the call.  All I know is that I have a
form of coroutine nursery working with my event driver that, except for
"cancel scopes," whatever they may be.

  -spc