Re: [LuaCheia] Let it begin.

[RLake@...]

Thatcher Ulrich escribió:

> My opinions on LuaCheia:

> * Great plan!  This is more or less what I had in mind when starting
> with the Lua Binary Modules.  I'm glad to support the goals of the
> project.

I agree.

> * I would like to propose the existing Lua Binary Modules code as a
>  base for LuaCheia.  I think it serves as a decent proof-of-concept,
>  and there are already end-users doing useful work with it.  It seems
>  to be the furthest along of any module-based Lua standard, so I
>  would like to see LuaCheia pick up the code and run with it.

I think Lua Binary Modules is great for Lua 4, but I would personally
like to see a Lua 5 binding mechanism which takes more advantage of
the new facilities of Lua 5. It would be a shame not to do this :)

LTN 7, while excellent, was written before Lua had full lexical binding.
It is now possible to completely avoid use of the global namespace, and
I think this should be done. The modification is quite simple: a module
file does not modify the global environment at all; instead, it returns
a table. It is then up to the module consumer to give that container
a name.

I would add a few more desiderata:

1) There needs to be a mechanism for module naming which is workable,
   scalable, and does not clutter code up with lots.of.dotted.subtables.

2) There needs to be some mechanism to allow for sandboxing
   (or some other security system, but I like sandboxing).

3) It should be relatively transparent whether a module is written
   in Lua or is binary, subject to the above.

For example, I would expect to write something like this at the top of
a file which used modules:

local io = requiremodule "core:io"
local regex = requiremodule "stdlib:posix:regex"
-- (or should that be requiremodule "cheia:posix:regex" ? )
-- etc.

In terms of naming, I would suggest the following:

1) Modules have "official aliases" which refer to a *documented* interface.
   That is, in the above example, an implementation of "core:io" would
   implement the io interface as described in the Lua manual.

2) The hierarchy is from general-to-specific, and separated with colons,
   but does not imply any sort of inclusion, derivation, or subclassing
   relationship. (Dots would also be a possible separator.)

3) There is a standard mechanism for associating official aliases with
   actual "locations". This could be in the form of a configuration file
   which maps aliases to access mechanisms; this file would, of course,
   be a Lua executable. It might look something like this:

   return {
     ["core:*"] = "file:/usr/share/lua/core/",
     ["stdlib:posix:regex"] = "file:/home/rlake/lua/myregex.lua",
     ["stdlib:posix:*"] = "file:/usr/share/lua/posix/",
     ["stdlib:*"]
= "file:/usr/share/lua/;http://luacheia.org/stable/stdlib/";
   }

In terms of transparency, it might turn out to be easiest if all binary
modules were loaded with a lua stub.

The security issue is the most troubling, but I feel very nervous about a
system which allows arbitrary programs to load arbitrary binaries, useful
though that might be in many cases. One possibility would be a mechanism
which defines specific directories from which binary modules can be loaded;
it would be necessary that a sandboxed lua-script could not modify this
list. (Of course, the system administrator would have to be responsible
for not putting unsafe binaries into these directories.)

The requiremodule interface should allow the possibility of requiring
specific versions of modules. One of the nice things about using local
variables, as illustrated above, instead of globals, is that it allows
for the possibility of multiple instances of the same module (say, versions
2 and 3, or perhaps my implementation and Thatcher's implementation.)

Comments are welcome....

Rici