Re: reinstating "in env do ... end"

[Duncan Cross <duncan.cross@...>]

On Tue, Aug 17, 2010 at 9:52 AM, Richard Hundt <richardhundt@gmail.com> wrote:
> Hi Lua Authors, List
>
> Please don't shoot... but I have to ask because I really liked lexical
> environments in work2. Is there any chance of reinstating the:
>
>   in env do ... end
>
> construct as sugar for:
>
>   do local _ENV = ... end
>
> ?
>
> The only justification I have for it is that it's not ugly (actually quite
> the opposite). To me everything else about Lua 5.2 is beautiful, except
> overloading un-prefixed symbol lookup/update by assigning to _ENV (the
> semantics are perfect, I just find it ugly).
>
> Anyway I thought it might be worth considering in light of the new and
> improved Lua implementation (no more function environments, etc.).
>
> If you all feel like hitting me with a stick now, then perhaps just remove
> it from "The Complete Syntax of Lua" in the docs:
>
> http://www.lua.org/work/doc/manual.html#9
>
> Cheers,
> Rich
>


I realise this is "their problem", but I think that in many people's
minds 'in env do' implies a lot more magic than the sugar is actually
providing, and explicit assigning to _ENV as a local variable is more
likely to force them to see how it actually works rather than how they
hoped it would work. It may be ugly, but it's less confusing.

In particular I remember when it was first mooted it seemed like quite
a few people assumed at least one of the following, and were surprised
if not frustrated when it turned out to be wrong:

- Bad assumption 1: Any function call inside an "in" block uses
variables from that block, not the environment it got when it was
defined:

  local print = print
  local function print_message()
    print(message)
  end
  in {message = "hello world"} do
    print_message()
	-- /!\ expecting 'message' to be looked up in this table
  end

- Bad assumption 2: The constructs are hierarchical - if something is
not defined in the innermost "in", it will go up through the parent
scopes until it finds it:

  in _G do
    in {message = "hello world"} do
	  print(message)
	  -- /!\ expecting 'print' to be looked up from _G
	end
  end

Now maybe this is just a documentation/education problem, but to me,
solving that problem and making damn sure that the laziest of users
really understands the subtleties of "in" seems like too much of a
headache for something that is, after all, now only sugar.

-Duncan