lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Sven (and subsequently Sean):

I've been trying to communicate to you that toying with _ENV or creating a new _ENV that "falls through" to the original is not always appropriate when I'd like to globalize all (or select) functions from a module.  Especially when working within sandboxes or other strange environments prepared for you.  It's not a question of "do I want to do this", it's an uncertainty about how I might mess up the behavior of the environment by polluting _ENV.  I'm just going to go with the argument that local access is faster than global access?  Yay!  Glad we settled that :-)

I get a sense from what you've written in previous postings that you (and Sean) are strongly against feature creep.  I mean there are postings on lua-l all the time about people wanting to add `x' to Lua and hoping upstream or enough of the community will agree (like here).  I would understand if it's easy to get into the habit of discouraging every proposal simply because you want to protect a minimal core (I do love that core <3).  There are a lot of good ideas out there, a lot of fun things that could be added, but it's tricky to decide which are worth supporting for the most benefit to everybody.  I imagine it's easier to just lock the door and turn out the lights -- so to speak.  I don't see this as a huge addition that would up heave the principles you revere in Lua.  It doesn't mess with or add to the grammar, it's not adding another standard library of functions, it would simply help cut down on the list of local reference ~noise~ that precedes and muddies most scripts.  You have at least 3 people telling you those lists are hard to quickly glance through for correctness. :>

I do find it amazing you and Sean would be this passionately against this -- it gave me a "dont be lazy" impression?  Maybe I'm lazy for not wanting to write 10-20 lines of local references (depending on the situation), I just see it as something that keeps people from scripting comfortably in Lua.  We've all been in those situations where writing the module name before each function becomes tedious and we'd rather have a short local identifier to call upon.  My point: I don't stick around to use languages that don't save me time.  I've been proud to script in Lua over other languages for 3-4 years now because of its clarity, but I know for an absolute certainty that what I'm talking about is an eyesore and/or a tedious preamble to write for many others.  This could be better.

Sadly I have already resigned myself to the fact that this won't happen without a major change to how Lua "looks for" locals.  I really appreciate S. Donovan's input for helping me understand why this isn't easy to do, currently.  I'm sure it would take a lot of work to make this possible, I'm just trying to assert that there is a need.  I don't agree that doing this through _ENV or just dealing with it is a proper solution.

PS: I was being sarcastic/coy with the "trendy"


As far as I know, assigning to the allocated locals would involve a table lookup *once* at runtime -- the local access would still be faster?  Maybe I'm wrong? :>


I knew I wasn't alone :D  I just disagree with preprocessors used with scripting languages, oh well..

Peace ~

On Mon, Nov 18, 2013 at 10:02 PM, Andrew Starks <> wrote:
On Mon, Nov 18, 2013 at 3:47 PM, Tim Hill <> wrote:
> For myself, if I do have a bunch of “local x = tx.” statements in production code, I just wrap them up into a generator macro (I generally use a macro processor with my Lua source code to help out with stuff like this). This reduces typing but doesn’t mess with the language.

On topic and probably worthy of its own thread. I'm sure they're out
there but some kind of momentum behind a common macro processor for
Lua would be "nice to have." That does seem like the simplest way to
address (what i see as) the most relevant annoyance --- the ten foot
variant of:

`local print, table, pack, unpack, pairs, ipairs = print, table,
table.pack, table.unpack, pairs, ipairs`