require, module, globals and "magic"

[Nevin Flanagan <Alestane@...>]

So, there has been much discussion lately on the usefulness of "module", whether modules should be globally loaded by their creating chunks, how environments should be handled, and so forth, and a few ideas refused to let me fall asleep, so here are my thoughts.

A large part of the tension seems to be between the "purity" of restraining global communication and the eminent usability of require and module in their current form, which is pretty undeniable. It seems to make little sense for common existing cases to mandate that the caller requiring a module save and place a reference to the module in most cases when the existing usage is so conveniently complete.

Putting control in the hands of the caller, however, seems to make sense. So I would recommend that 5.2 retain the default behavior of exporting a loaded module into the calling environment, but as part of require, not module. This allows require to be used in its current fashion, but since require is relatively trivial to reimplement in Lua (most of the work is actually done by the contents of package.loaders), those using require who dislike the globalization can override require to eliminate it. (Alternatively, require could take an optional parameter which controls this behavior. But I think that for the time being, require's default behavior should have the same net effect, even if the creators wish to say that that side effect is deprecated functionality.)

There is not a lot of use for module, but it could be retained as a convenience function with reduced functionality...mostly a shorthand for (simplified) "return package.loaded[name] or _ENV[name] or {_NAME = name}". It could then be used in the construct "_ENV = module(myName)" to preserve module's current attempt to reuse existing tables if they have already been created. But I agree that it should not force an environment change or inject itself into the calling _ENV or package.loaded; those responsibilities should be delegated to require where they can be controlled by the caller.

Nevin Flanagan