Re: [poll] require & binary module interfaces

[Nilson <nilson.brazil@...>]

On Fri, Oct 22, 2010 at 12:37 AM, David Manura <dm.lua@math2.org> wrote:
> 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"?
>
>
Orthogonality: What x Where

I was wondering if we could split - just for analysis - this issue in
two subproblems:
- What you require (and maybe what you want readers of your code
should know) and
- Where you'll find it.

Thinking in this way we could make a "cartesian product" to analyse
the current Lua's solutions to each combination.

What dimension:
a) the base module <require "a" >
b) only the submodule explicit required <require "a.b">
c) the base module and all the submodules like <require "a.*">
d) other possibilities.

Where dimension (David Manura):
>  (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.
5) other ways to find it.

As I don't have the necessary expertise in Lua to handle all
combinations, I will stop for now.

Cheers,
Nilson