[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: scope-aware values
- From: Luiz Henrique de Figueiredo <lhf@...>
- Date: Sun, 20 May 2007 23:44:16 -0300
> 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