[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