Re: require, module, globals and "magic"

[steve donovan <steve.j.donovan@...>]

On Mon, Aug 16, 2010 at 5:13 AM, Nevin Flanagan <Alestane@comcast.net> wrote:
> 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.

If you control all the source, then this could work fine.  But a
single importing require somewhere would disturb the scheme's purity.

Personally, I think it's possible to get overexcited about purity.  We
are accustomed to the standard libraries being globals, so keeping
track of another dozen or so globals is no great challenge for person
or machine.  A disciplined person will still say "local mod = require
'package.mod'" upfront.  The real problem is that not all
commonly-used modules behave in the canonical form, i.e. that
require() does indeed return the module, and that the global module
name will be 'package.mod' in the last case.

Increasingly I believe that Lua development environments have to get
smarter, rather than making the language stricter (David Manura's
lua-inspect is a good example). In this canonical use of require(), we
can statically infer that 'package.mod' is a known global.  We get to
the point where a useful incremental spell checker for Lua could be
constructed.

This is also an argument for good old 5.1 modules-as-namespaces (warts
and all).  The only globals available when using module()  (if
avoiding package.seeall) are module-scope names, which require() would
never affect.

steve d.