Re: [ANN] Lua 5.2.0 (work1) now available

[Nevin Flanagan <Alestane@...>]

On Jan 9, 2010, at 12:11 AM, Ben Kelly wrote:
> That said, something that lets you, given a function, create a new
> function with the same code and a different environment (without needing
> to dump->load it and thus destroy its upvalues) would also suit my
> purposes. As it is, though, it looks like setfenv is being removed
> without replacing it with anything.

While I myself am enchanted with the idea of lexical environments, I agree that a mechanism for creating a copy of a closure with a designated environment should be useful and should remain clean.

I am slightly concerned about the inability to pass things across the boundaries of an in block via the stack. Unless some connection is made between the two environments, the only way to pass information in or out (out is more significant here) is by declaring a local outside the in block in which the block contents can leave messages for the code outside the block. This seems contrary to the very functional nature of Lua and I would like to see some way of passing information out (or in) via the stack. Something along the lines of:

local processor = in containedEnv with operation, parameter do 
	local operation, parameter = ...
	return function (...) return operation(parameter, ...) end
end

The "with expressionList" construction would be optional, but if present these would be passed into the block as a ... vararg (using named arguments is a slightly more complex proposition whose merits could be debated). The local just assigns names back to them within scope. You could also supply unnamed expressions in this list (such as table or function constructors) and then access them inside the block via the ... expression.

The other proposition is to allow return statements inside an in block to allow values to be passed back out on the stack; an in block would qualify as an expression. So, this would set processor in the scope outside the in block to be a function that called operation with parameter (as an upvalue) along with any call-time arguments, but with containedEnv as its environment.

If people have other recommended syntax or forms for accomplishing these tasks, I'm happy to see them discussed, but I would very much like to see some stack communication across the block boundaries in some form.