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

[Richard Hundt <richardhundt@...>]

On 08/17/2010 11:40 PM, Richard Hundt wrote:
> 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.

[...]

> 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.

On further reflection, I take that back. If I think of _ENV more as a 
hook provided by the compiler, then it all makes perfect sense.

Thanks again for the explanation.

Cheers,
Rich