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

[Richard Hundt <richardhundt@...>]

On 08/17/2010 04:04 PM, Jerome Vuarand wrote:
> 2010/8/17 Roberto Ierusalimschy<roberto@inf.puc-rio.br>:
> > Besides this problem of bad assumptions, _ENV is also more flexible.
> > (For instance, it provides an obvious way to access the current
> > environment.)
> >
> > (But I agree that it is not particularly pretty...)
>
> I was thinking about why it's not pretty, and had a weird idea.
>
> _ENV looks ugly, because it's uppercase. _G had the same attribute,
> but since it's a single letter, it's like a particular glyph, not an
> uppercase word. The alternatives to _ENV are :

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.

That's why I thought it was nice having it hidden behind its own 
syntactic construct, instead of re-using assignment. That said, a bit of 
fiddling with your editor's syntax highlighting rules and _ENV can be 
made to look less "ordinary".

Then again, Perl does this sort of thing with abandon: @INC, @ISA, $/, 
$| ... assigning to any of these (and a couple of dozen more besides) 
has side effects.


> - A single letter word, like _G or _E
>
> A bit better, but some people already find _G ugly too.
>
> - A lowercase word
>
> Yet another keyword. But here it's clashing with variable names,
> especially since _ENV appears in the same place as variables (as
> opposed to most other keywords).

I think with the magic-ness of _ENV I'd rather it were easier to spot. 
It's not like _G or _M or any of the others. It's overloaded.

> - A new non-alphanumeric character
>
> What about $, #, or @ ? People may argue (and I'd agree) that we don't
> want Lua to become Perl-ish line noise.

That's not bad. JavaScript has $ as a generally usable symbol prefix, 
but the intention is that it signifies machine generated variables. I 
could live with @ENV.

> So I thought, what about reusing an existing non-alphanumeric symbol,
> and then the ellipsis "..." came to my mind. Wouldn't that be possible
> to merge the ellipsis and _ENV in a single concept ? "..." would be
> the name of a special variable holding a table (or any indexable
> object), the "(mixed) environment" that would serve two purposes :
> global variables ("variables environment"), and (unnamed) function
> arguments ("arguments environment").

I think there's little mileage in reusing syntax to mean different 
things - your suggestion of reusing of "..." for example - since that 
just adds cognitive load because you have to take the context into 
account to understand what the syntax means (it won't always be obvious 
whether you're indexing ... with a string or a number).

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 ;)

Cheers,
Richard