lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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.