lua-users home
lua-l archive

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

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(" 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]
> [2]
> [3]

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.