1) I do agree that not seeing the direct declaration of any identifier can lead to confusion -- I also dislike preprocessors. Mainly because I think it's a bit strange to have to invoke a separate script to preprocess an interpreted language, and then use another script to check for unused locals or globals. I don't like that globals.lua module floating around because of what it does to _G, either..
2) I don't agree with Sean's advice to use my text editor or an external preprocessor to generate the list of local declarations. Yes that saves keystrokes, but I'm moreso trying to reduce the complexity of *reading* that list than writing it. I think import(os) & import(table, { 'insert', 'remove', 'unpack' }, 't') & import(string, { 'byte', 'char', 'find', 'format', 'rep' }, 's') is easier than reading/skimming 19 local declarations/lines. Is this really that hard to understand?
3) My mistake for making it seem like I was primarily arguing that locals are better for performance and this should be the biggest reason for having an import(). The main reason *is* brevity. But if I say brevity I'm treated like I'm lazy, if I say efficiency I'm flooded with "well why not LuaJIT?", and no matter how many times I try to politely remind people I'm still reading suggestions involving _ENV. I get it: For most cases touching _ENV works, but I do not agree that is is convenient or appropriate ALL the time. I still get this overwhelming sense of "feature suggestion? BURN THE WITCH" from this list. I only picked the local-vs-global performance reason after arguing for a while over not touching _ENV because people (mostly Sean) kept telling me to use _ENV. I mean I said in the first email I wanted to avoid solutions involving _ENV... There are so many things you can fuck up by touching _ENV or by creating new one(s). I have seen several people misguidedly define the metatable of the *existing* _ENV. It's easy to forget to define the __newindex to you can set globals in the existing _ENV as well. I don't want to think about this and I feel like for this purpose you shouldn't have to.
Let's consider the _ENV approaches anyway. I see two schenarios:
I can write a function called from() that is called in the same form I've been describing of import(). It'll create a new environment and set the __index to the previous, inherited _ENV, and return this table so I can do: _ENV = from(string, { 'byte', 'char', 'find', 'format', 'rep' }, 's')
The problem is if I have several lines like this:
_ENV = from(table, { 'insert', 'remove', 'unpack' }, 't')
_ENV = from(string, { 'byte', 'char', 'find', 'format', 'rep' }, 's')
_ENV = from(math, { 'abs', 'log', 'modf', 'sin', 'min', 'max' })
This essentially creates a "chained" _ENV of 4 tables. Suddenly the locals seem more efficient. So let's change that to create only one _ENV table at a time:
_ENV = from({ table, { 'insert', 'remove', 'unpack' }, 't' }, { string, { 'byte', 'char', 'find', 'format', 'rep' }, 's' }, { math, { 'abs', 'log', 'modf', 'sin', 'min', 'max' } })
...but this looks really crazy and I'd rather just have the long list of local declarations instead, or create the new _ENV literally rather than through this nonsense. :\
Here's the code for the first just for fun:
local from =
function (t, ...)
local pref, keys
if select('#', ...) > 1 or (... ~= nil and type(...) == 'table') then
keys, pref = ...
else
pref, keys = ...
end
keys = keys or {}
pref = pref or ''
if not next(keys) then
for k in pairs(t) do
table.insert(keys, k)
end
end
local new_env = setmetatable({}, { __index = _ENV })
for _, k in pairs(keys) do
new_env[pref .. k] = t[k]
end
return new_env
end
I did that kind of quickly so sorry if it looks pretty bad...
Anyway, I recognize that most of the people who replied are _not_ in favor of this and that I have *lost*. I do want to say I am pretty upset about how discouraging a lot of people on this list can be when all they see is "Suggestion for 5.3" and go into attack mode without reading the proposal to the end. I did sort of expect it to get a negative response, as I have seen similar proposals on lua-users but I was hopeful :p I'm just saying that the community involvement with upstream is through this list and an overall attitude like this will probably hurt Lua in the long run. Or maybe I'm just moping.. ~
Usually I read this list through gmane, I forgot about this email account and only started logging in again a few days ago. There are a ton of good ideas that pass through #lua on freenode that never make it to lua-users or this list... They aren't community-reviewed, they're just lost. Sometimes I feel like LuaJIT and its advancements only exists because upstream moves a tad slowly/conservatively. Maybe it is easy to fork Lua or to patch it for some simple extension but I wonder if even the drastic changes made between 4.0 and 5.0 would even be possible with a community like this nowadays. Oh well, not a democracy.
Again, I do want to thank the people who took considerable care/time to come up with something constructive in this thread. I did learn and I am appreciative.
