Re: Idea for 5.2 : merging _ENV and ... (was: Re: reinstating "in env do ... end")

[Richard Hundt <richardhundt@...>]

On 08/17/2010 10:20 PM, Roberto Ierusalimschy wrote:
> > I think it's not pretty because what I want to say is: "redirect
> > global symbol lookup to this table", and not: "assign this table to
> > a variable". I realise, of course, that _by_ assigning this table to
> > _ENV, I get the lookup redirection, but that's implicit. This one
> > symbol in the language is overloaded. It's magic.
> >
> > [...]
> >
> > See that's part of my issue with _ENV = { ... }. It's a reuse of
> > existing syntax, but as a special case. However, nothing is perfect
> > and the consensus seems to be that we can live with this one bit of
> > magic in an otherwise perfect language ;)
>
> I am not sure you have a correct understanding of how _ENV works. Any
> reference to a "global" name 'x' ("global" here meaning a name
> without any local declaration) is always translated to _ENV. That
> is, if you write "x = x + 1", Lua reads this as "_ENV.x = _ENV.x +
> 1". That is all. Apart from this translation, _ENV is a completely
> normal variable. An assignment to _ENV is a completely normal
> assignment. There is nothing magic or special at all happening there.

Thanks. I can see the elegance in it.

I guess that would also mean that the GETUPTAB and SETUPTAB opcodes are 
not only generated for indexing _ENV, but for all tables which are upvalues?

I still see this as making the symbol "_ENV" itself special, though 
(emphasis on "symbol"); it is special to the compiler, if not special as 
a runtime entity.

However, I hasten to add, this is much ado about nothing really. I was 
just trying to contrast the "assignment to _ENV" syntax with using "in 
env do ... end" -- which really reads to me like "step into this env", 
instead of "assign to this variable".

So, it's all good and I think it's a clean and simple solution as far as 
the implementation goes, making Lua a better place for all.

Cheers,
Rich