Re: [poll] require & binary module interfaces

[David Manura <dm.lua@...>]

On Thu, Oct 21, 2010 at 12:36 AM, Wesley Smith <wesley.hoke@gmail.com> wrote:
> I'd still like to know whether people expect all modules inside a
> binary to be loaded by loading the base module or expect the
> piece-meal approach.

On Thu, Oct 21, 2010 at 2:44 PM, HyperHacker <hyperhacker@gmail.com> wrote:
> Large/rarely-used modules are why I suggested using metamethods to
> only load the module when someone tries to use it. __index on 'space'
> would do here.

Observe that dots in module names are used by Lua in these ways:

  (1) The `module` function creates (or reuses) tables for each dotted
component.  This is deprecated, with justification, in 5.2.0-work4
though.
  (2) The second searcher replaces dots with directory separators in
locating the Lua file (ASCII or binary).
  (3) The third searcher replaces dots with directory separators in
locating the C library file and then replaces dots with underscores in
locating the contained C library symbol.
  (4) The fourth searcher is like the third but only uses the first
dotted component in locating the C library file.

Note: #4 is intended for packing several submodules into a single
file, but it introduces a lack of orthogonality in that there is
nothing analogous to #2 in the same way that #4 is analogous to #3.
Furthermore, #3 and #4 are special cases (N=N_max and N=1) of a more
generalized searcher that iterates over N=N_max..1 in using the first
variable N dotted components in locating the C library file.  It's a
bit of a tangent, but this hints that perhaps Lua 5.2 should
generalize #2+4 and improve orthogonality by allowing this type of
thing:

  -- a.b.c.lua (possibly compiled with luac)
  if ... == "a.b.c" then
    return {test = function() print 'test' end}
  elseif ... == "a.b.c.d" then
    return {test2 = function() print 'test2' end}
  end

  -- a.b.c.e.lua
  return {test3 = function() print 'test3' end}

  -- main.lua
  require "a.b.c".test()
  require "a.b.c.d".test2()
  require "a.b.c.e".test3()

In all non-deprecated cases #2-4 above, dots are merely utilized by
Lua as an implementation detail to map modules to where they are
stored: Modules named with a common dotted prefix may be stored in a
related way.  Lua could of course relax this condition by redefining
the searcher functions such that module storage does not depend in any
special way on module name dots.

Back to your original question.... Indeed, there are two parts to this question:

  (1) Should require "a" load module "a.b" into memory?
  (2) Should require "a".b == require "a.b" ?

Assuming module loading has little or no functional side-effects, the
first is merely an implementation/performance detail.  For the second,
I would say that the decision is really up to module "a" to decide,
but the client of "a" cannot rely on this behavior unless "a" says so.
 It may be that require "a".b == require "a.b" but require "a".c ~=
require "a.c", with the typical reason being that "a.c" is not a core
part of "a" or perhaps it is completely unrelated to "a" (e.g. "a.c"
is a function provided by "a", while "a.c" is a module by a different
author, in a different LuaRocks package, and for a different purpose
but that just happens to use the same parent module namespace "a.").

Another thought: If your answer to question #2 is yes, then should
require "_G".debug == require "_G.debug"?