lua-users home
lua-l archive

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

On 08/17/2010 04:04 PM, Jerome Vuarand wrote:
2010/8/17 Roberto Ierusalimschy<>:
Besides this problem of bad assumptions, _ENV is also more flexible.
(For instance, it provides an obvious way to access the current

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