Re: scope-aware values

[Luiz Henrique de Figueiredo <lhf@...>]

> the Lua error() function behaves as a no-op when called with nil.

Not true, unless I'm missing something. error() or error(nil) still
interrupts execution of the current function. It simply does not
emit any traceback.

> This contradicts the Lua manual, but is a useful characteristic
> which I'd like to see formalized.]

http://www.lua.org/manual/5.1/manual.html#pdf-error says "Usually, error
adds some information". Since usually error is not called with nothing
or nil, it seems to me that the manual is not completely wrong...
--lhf


> We've now introduced some ambiguity though.  Consider when there are
> multiple "scoped" variables within a given scope, each of which are
> supposed to be called on exit.  What if two or more raise exceptions?
> Should this be a fatal error?  If not, which exception do we finally
> propagate?  I'd rather avoid this mess by adding the constraint that
> there be only one "scoped" variable per scope.  Applications can decide
> how to resolve these situations via their scope manager.
> 
> Here is an alternative to adding the "scoped" variable class.  Say we
> have a "with..as" statement similar to Python [4].  This is not the
> Pascal "with" which opens up an objects members to the local scope,
> which is apparently unworkable in Lua [5].  Rather, it's a way to define
> a single value which manages a new scope, along with a variable for
> accessing that value.  Like Python, binding to an explicit variable (the
> "as" part) is optional.  So for example:
> 
>   function with_output(f, func, ...)
>       with ScopeManager() as sm do
>           local out = io.output()
>           sm.on_exit(function() io.output(out) end)
>           io.output(f)
>           return func(...)
>       end
>   end
> 
> and here is a try-except:
> 
>   with function (e)
>       -- Except block.  E.g.:
>       --   Use e for conditional catch
>       --   Re-raise with error(e)
>   end do
>       -- Try block
>       --
>   end
> 
> I think "with" could be employed for other interesting things by way of
> some extra metamethods.  Instead of overloading the call metamethod on
> scope exit, we could add an "exitscope" metamethod.  Maybe an
> "enterscope" would be useful too.  And although opening up the objects
> fields doesn't work for writes, I think it would still be useful for
> reads.  Then with our ScopeManager we could avoid the "sm" variable
> altogether:
> 
>   function with_output(f, func, ...)
>       with ScopeManager() do
>           local out = io.output()
>           on_exit(function() io.output(out) end)
>           io.output(f)
>           return func(...)
>       end
>   end
> 
> 
> Just some ideas to toss around-- I should really be writing my Gem.
> 
> --John
> 
> 
> 
>  [1] http://www.digitalmars.com/d/exception-safe.html
>  [2] http://www.ddj.com/dept/cpp/184403758
>  [3] http://lua-users.org/lists/lua-l/2005-08/msg00357.html
>  [4] http://www.python.org/dev/peps/pep-0343/
>  [5] http://lua-users.org/lists/lua-l/1999-07/msg00037.html