Re: stack level parameter

[Mark Hamburg <mark@...>]

On Jan 18, 2010, at 8:37 PM, David Manura wrote:

> On Sat, Jan 9, 2010 at 4:34 PM, Cosmin Apreutesei wrote: [1]
>> I always felt that the stack level parameter in
>> setfenv() and error() is just a hack, and I'm happy to see it go away.
> 
> I agree with the sentiment: Whenever I add a level parameter to an
> error to setfenv/getfenv, it usually feels fragile or potentially
> wrong.  How does code know the appropriate level parameter of its
> caller?  For example, the setfenv in package.clean [2] makes an
> implementation assumption of stack levels inside the module function.
> It gets more complicated if a function can be called from multiple
> levels (e.g. directly or from a wrapper function).  There's also a
> theoretical dilemma: given a function f, you can't necessary define a
> function g that wraps f and behaves identically [3], though you may if
> f exposes a level parameter as an optional argument.  Idioms like "f =
> assert(io.open(.....))" don't attempt to provide a level parameter,
> but you can localize a redefinition of assert to do so.
> 
> There are mechanisms, not out-of-the-box, one can devise to deal with
> it, and early on I had some experiments with LuaCarp a la Perl Carp
> and then [3], but unfortunately I don't have a solution in mind that I
> can with certainty say works really well in practice in all use cases,
> tail calls, and code by different authors and that I might suggest for
> 5.2.
> 
> [1] http://lua-users.org/lists/lua-l/2010-01/msg00420.html
> [2] http://lua-users.org/wiki/ModuleDefinition
> [3] http://lua-users.org/lists/lua-l/2009-09/msg00437.html
>     http://lua-users.org/lists/lua-l/2009-09/msg00384.html

This is arguably one of the strongest arguments for the dynamic scoping proposal. in-do-end already deals with one of the chief reasons to use a stack level index in setfenv. Dynamic scoping would deal with one of the chief reasons to do an indexed getfenv.

Mark