 |
lua-l archive |
|
|
||
|
Jay Carlson <nop@nop.com> wrote:
> Although the modern all-local model for imports has saved much frustration, it's kinda nasty about two things:
>
> 1) It fails "Don't Repeat Yourself", and fails it in programs two steps beyond "hello, world". local ml,sqlite=require"ml",require"sqlite". This is not a pretty thing to show off to beginners. The alternative is ml=require"ml", and we seem to be trying to discourage that. Or as proposed, go back to a require-replacement which sets _G.ml.
Another option would be to have some means of creating local variables by the require directly... but that may be introducing too much magic into the language.
> 2a) Interactive development of modules. Single-module reload is hopeless. Everybody has a local pointer to your table, and they'll be using the old table. [...]
>
> 2b) As things moved from _G into modules (like table.*), a lot of code got big lists of abbreviations at the top, in the name of efficiency, conciseness, and immunity to _G poisoning. local tinsert=table.insert. If anybody has stashed a local copy of mymodule.write, it doesn't matter if you updated the mymodule table in-place.
>
> 2c) Random closures floating around will have lexically localized old versions of mymodule.write.
>
> I think much of both #1 and #2 is a desire to use short names for references--and not take the efficiency hit of traversing _ENV.packages.loaded.mymodule.write in an inner loop. If modules had an aliases block which could be triggered on change-of-environment, that'd cover most of it. I dunno, hoisting inner declarations into that block is the logical next step, maybe.[1]
>
> I don't think this is "as simple as possible but no simpler," but probably unlike most people, don't-repeat-yourself has been driving me nutty lately.[2] This is yet another lexical environment problem--if you think it's a problem at all. Nobody is going to chop off your head for using _ENV.
Jay:
You've managed to sum up my own disquiet about the existing module system for Lua 5.2.
I've been thinking about this issue on and off for nearly a year. And I don't have a solution, but I do have some ideas.
---------------------------------------
From what I understand, a considerable part of the motivation for moving imported modules and their individual functions into local variables is performance, as you allude to.
What if we tried to fix this issue from the other direction, and make accessing frequently used table values as quick as a local reference? What if this also worked for OO programming, so that even when accessing a method from a parent class through the object's metatable, it was just as fast as a local?
Certainly we want people to keep using local variables when appropriate, and we don't want to encourage pollution of the global name space.
LuaJIT can detect and hoist these table accesses outside of tight loops and other places where it would matter. Can this sort of thing be implemented in Lua, without a heavy penalty in terms of code size and complexity?
---------------------------------------
In a different but related direction, I'm thinking about a more general mechanism to cache table contents accessed via a chunk of code. I would also like this done when the lookup is going through metatables.
The results would be cached in a fashion similar to local variables. The cache would be invalidated when the table is changed. Since the Lua state is single-threaded, I don't see any theoretical difficulty to implementing this.
Practically speaking, I'd see this as being tricky to do. However, it could really speed up many kinds of programs, especially OO ones.
---------------------------------------
There were also some productive discussions last year about re-implementing the 'module' function for Lua 5.2.
I thought maybe we were headed towards a consensus there, but the discussion just died off.
---------------------------------------
So, I'm not satisfied with the current situation, but I hope we can keep talking about it, and figure out something better.
James Graves