Local as table

[Andrew Starks <andrew.starks@...>]

So, I was thinking about the amusement I get from reading the posts on
this list from people that complain about the cost of creating a table
or the relative speed of global access vs. local access. You'd think
that some of you were writing scripts for massive games or template
engines for giant web services! :)

Anyway, I abuse _ENV every day by making a module that I import into
_ENV, so that I don't have to drone on and on for three lines with:

local print, ipairs, pairs, load, ... = print, ipairs, pairs, load, ...

I don't have a speed motivation for doing this. Since I've switched to
5.2, I use _ENV for the same (and even better) effect: to a specific
subset of the Lua global environment that I'm using and to then limit
my space to only this. However, I am under the impression that the
_ENV table has the exact same behavior as the _G table, since it
defaults to being its alias. So, my understanding is that, for those
that are using the above preamble in their modules to speed access to
library functions cannot use the `_ENV = require"mymodule._ENV"`
method.

This all made me think that if Lua had a macro processor, turning a
table into pre-defined locals would be pretty trivial. Something like:

#local {print = print, ipairs = ipairs, load = load}

or more to the point:

#local = require"mymodule.mylocals"

The intended benefit is that these would be true locals, complete with
local scope and speed benefits.

Of course the leap from `local print = print` to `local.print = print`
or, if you like `locals.print = print`,  is a short and nauseating
one, for most people. :)

I just thought it was interesting to ponder the concept of local
variables as being contained in "the local table", at least
conceptually. (I assume that this isn't true in the implementation of
Lua.)

-Andrew Starks