Re: idea of vision of blueprint of ROADMAP of Lua core

[Spencer Schumann <gauchopuro@...>]

> Wow, I think I'd be quite lost without fenv().  Global lookups from
> an upvalue is an interesting idea but I'm not sure it'd all work
> out simpler (either semantically or from an implementation pov) than
> the current scheme in reality.

I also rely upon fenv(), but I think they could use an addition:
currently, each function is associated with one fenv.  In some cases,
you need to have identical functions that are each associated with a
different fenv.  In pure Lua, this can be solved by making sure each
function is a distinct closure, or by using string.dump() and
loadsttring() to make duplicates.  The method I'm using right now is a
"clone" function added to the Lua core that makes a copy of a function
(by creating a new closure using the proto of an existing function),
and these copies can all have separate fenvs.

>  > -  coroutines (is there *anyone* at all who agrees??  :-)  )
> 
> They're fantastic (albeit not essential) as iterators.  Apart from
> that I don't use them myself, as attractive as they are from a
> 'computer science' angle.
> 

Coroutines were part of the reason Lua was chosen for my current
project.  I need to be able to run multiple concurrent scripts, and
coroutines provide a very lightweight way to do that.

> I rely on mutable closures for a few things.  I'd be sad if they
> went away, but would survive.  Wouldn't it kill module-top-level
> locals though, since these are treated as mutable upvalues
> in functions that reference them?  Again, though, I'm really
> not sure that making a closure a read-only copy of the var's
> last value at the point it leaves scope would be *at all* simpler
> to understand or implement than the current scheme.

I agree.

>  > And some pluses:
>  >
>  > +  __pairs metamethod
> 
> Although this would be academically pleasing and the lack of
> such a metamethod seems like an obvious hole in proxy tables
> etc, in real life I seem to be living quite comfortably without.

I think a __pairs metamethod would be useful, and I'm considering
adding one myself.  The big trouble is that there are multiple ways of
iterating through some objects, such as pairs() and ipairs() for one. 
Perhaps it is sufficient to keep the current method of allowing
arbitrary iteration functions.

>  > +  __settable, __gettable metamethods

There is a "hole" in that there is a __newindex metamethod, but not a
__setindex metamethod...perhaps that is what this suggestion is about?