Re: The removal of function environments: An opportunity for optimization?

[Mark Hamburg <mark@...>]

On May 24, 2010, at 7:00 AM, Roberto Ierusalimschy wrote:

> The bigest problem with this idea seems to be the "identification" of
> different functions into one. This seems rare, but may cause quite hard
> bugs. (Imagine the emulation of the old setfenv, using 'upvaluejoin',
> over such clones...)

Yes, this optimization would pretty much make it impossible to emulate the old setfenv since the existence of setfenv is what forces the creation of new functions even when they would otherwise be equivalent. My feeling on this is that if setfenv is going away, then it goes away and there shouldn't be a constraint to keep an emulation working.

The other thing this breaks is if one were using functions simply as unique values. There are plenty of other ways to achieve that, however.

Beyond making little functions cheaper in various contexts, here is an example of what I would hope to be able to write with this optimization in place:

	function with_mutex_do( mutex, ... )
		mutex:lock()
		return ( function( mutex, ... )
			mutex:unlock()
			return pcall2call( ... )
		end )( mutex, pcall( ... ) )
	end

Without this optimization, the inner function needs to be pulled out into a helper function that doesn't get "read" in context.

That said, this is still pretty convoluted, but it has to be because we need to collect up the varargs result of pcall.

Mark