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

[GrayFace <sergroj@...>]

I would definitely prefer setfenv over this optimization. Also don't 
forget that the function itself may potentially change _ENV, as far as I 
understand.
In fact I don't quite understand what _ENV is.

function f1()
  return f2()
    _ENV = {}
  end
end

Would execution of f2 lead to a change in _ENV of f1? If _ENV is a 
regular upvalue that may be shared, then it would. If it's not a regular 
upvalue or an upvalue that's always unique, than what's the difference 
between it and function environment?
In case it's a regular upvalue, a 'uniqueupvalue' function would be 
needed to implement setfenv. It should make an upvalue of a function 
unique, not shared with other functions. As far as I understand, it may 
be problematic to implement.

On 24.05.2010 21:31, Mark Hamburg wrote:
> 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.

--

___________________________________________
Best regards,
Sergey Rozhenko                 mailto:sergroj@mail.ru