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

[Jerome Vuarand <jerome.vuarand@...>]

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 :

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

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

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

Integer indices would contain the unnamed function arguments, string
indices would be the global variable accesses. There shouldn't be any
clash, unless the user use the explicit "...[key]" syntax to get or
set some specific variable. The content of "..." could be replaced by
another indexable object, just like the _ENV variable in latest -work
release, which would cover all special uses of _ENV and all tricks to
hide the function arguments for special code manipulation purposes
(that feature to assign to "..." was asked several times on the list).

There are open questions, about whether integer keys of "..." (the
"argument environment" part) would be shared between closures with the
same environment, or whether each call frame should get a special
"argument environment". It may not even be necessary to introduce a
new kind of object that forward string __(new)index to one place and
integer __(new)index  to another place, a regular userdata could do
the job. A custom environment (... = myobject) could easily emulate
such a behavior after all.

The more I think about it, the less stupid it sounds. Comments will be
appreciated :-)