[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: stack level parameter
- From: Mark Hamburg <mark@...>
- Date: Fri, 22 Jan 2010 07:06:10 -0800
On Jan 21, 2010, at 11:20 PM, M Joonas Pihlaja wrote:
> On Thu, 21 Jan 2010, Mark Hamburg wrote:
>
>> Yes though that code isn't quite right since it needs to actually
>> build something that looks up in env followed by the current
>> environment.
>
> I suppose you'll need debug.getfenv() for that, no? If you need to
> keep track of the current env yourself explicitly (say by
> side-effecting some state which you need to undo) then I'm not sure
> how it would work.
pushenv should probably have a corresponding currenv function. This is more restricted than getfenv's ability to go probing around the stack. This sort of function would also be useful for implementing things like:
function wrapWithCurrentEnvironment( fn )
-- Creates a version of fn that always executes in the current environment
local env = currenv()
return function( ... )
in env do
return fn( ... )
end
end
end
On the other hand, this isn't essential. Pushing an environment could redefine pushenv (which is itself being accessed as a global) so that it knew about the current state of the environment stack without exposing that knowledge elsewhere. pushenv would build a new environment table with the appropriate inheritance chain and a new definition of pushenv.
Mark
- References:
- stack level parameter, David Manura
- Re: stack level parameter, Mark Hamburg
- Re: stack level parameter, steve donovan
- Re: stack level parameter, Mark Hamburg
- Re: stack level parameter, steve donovan
- Re: stack level parameter, Mark Hamburg
- Re: stack level parameter, M Joonas Pihlaja
- Re: stack level parameter, David Given
- Re: stack level parameter, Mark Hamburg
- Re: stack level parameter, M Joonas Pihlaja