Re: Declared UpValues, change to Parser.

[Sean Conner <sean@...>]

It was thus said that the Great Duane Leslie once stated:
> > I'm not sure I understand this.  An example?
> 
> A trivial strict environment is just to set _ENV to nil, and then
> declare everything as local variables.  This doesn't work exactly the
> same way for closures because they can see the locals up the tree
> (i.e. upvalues) in addition to their locals.  Most of the examples I
> can think of either extend the strict error checking or are hugely
> convoluted.  One useful example I can think of is as follows:
> 
> ```lua
> local pairs, print = pairs, print
> local _ENV = nil
> 
> local a = {}
> local function b (_ENV) <> -- empty upvalue list
>   a, b, c = 10, 20, 30
> end
> 
> b(a)
> 
> for k,v in pairs(a) do print(k,v) end
> ```

  Okay, so you want to catch as many errors during compilation instead of at
runtime.  Okay.

> With the `<>` declaring an empty upvalue list the `a,b,c` values are
> bound to the `_ENV` parameter.  Without it the compiler prefers to
> bind to local variables before _ENV, and so you destroy the table and
> function.  If you don't pass in the `_ENV` parameter the code will
> actually fail to load since `c` is not declared anywhere and cannot be
> retrieved (since there is no `_ENV` parameter, not even a nil one).

  This seems like a contrived example, and I'm still having trouble
following it, or even understanding what the user is expected to write.  

> > _ENV is not always guarenteed to be the first upvalue, or even the first table upvalue
> 
> This is exactly the problem I started out trying to solve.

  It sounds like you are trying to solve several issues, unless I'm terribly
mistaken.  

  -spc