Re: Binary Modules for Lua [was Re: External modules]

["Peter Loveday" <peter@...>]

Thanks for preparing this to actually get this idea off the ground!

Shame this isn't for 5.0; I can't really evaluate it properly as I don't use
Lua 4 at all.  However, some initial comments on what I can see:

Perhaps using the extension .dll on windows is not the best idea; Something
like .luamod or .luaext or something might clarify the purpose of the file.
Or maybe some other portugese word for something else astronomical that
sounds catchy :)

Never having used tolua, I'm unsure how this source works.  I presume this
.pkg file is passed to tolua, along with the SDL headers, and it produces a
binding?

So, as far as I can gather, a module only exports two symbols; lua_version()
and lua_import().
Firstly, lets change these names... it would be better if anything with lua_
on the start were a call to a standard lua_ library function.  Perhaps
luamod_ or something.

I presume the host app calls lua_version() on the mod, to determine if it
matches sufficiently.  How do we determine this?  Can we assume a major
version is always compatible? eg 5.0 will be compatible with 5.2, but not
6.0 ?

Then lua_import() is called, passing in the lua_State * to set up for.  Is
there any need for a means to clean up a state?  I suppose the module can
install some global object with a gc hook, but that doesn't gaurrantee any
order of clean up (ie there might still be module objects waiting to be
cleaned up, which means the module can't close itself down yet)


One issue that comes to mind here, is that a module must be capable of being
loaded by more than one state in the same Process (possibly on different
threads) at the same time.  ie, the code must be re-entrant, such that one
can say something like:

    lua_State *A, *B;
    ...
    lua_import(A);
    lua_import(B);


Namespaces: Perhaps the module should return a table to use as it's
namespace, such as:

    sdl = loadmodule("luasdl")

This of course doesn't confine the module to _only_ use this table, it is
more of a convention.  If something needs to be global, it could still do
so.


global metatable:  If the module changes the 'global' metatable, it must do
so cleanly.  i.e. not just replace the calls, but pass to the existing
metatable where appropriate to allow other modules to still function.

I like the loadmodule() name, it is probably clearer that uselib().

> I also think it's nice to be able to distribute a binary module that
> doesn't need a Lua wrapper at all -- only one file, only one path to
> worry about.

Absolutely, I agree entirely with this.  The simpler the distribution and
installation of modules the better.

> * I'm DEFINITELY NOT proposing that "loadmodule" be built into the
>   standard Lua interpreter.  I think this community standard can
>   function just fine as a consensus specification, centralized on some
>   pages at lua-users.org, without altering the standard Lua
>   distribution in any way.

While it doesn't need to be built in, at least having a standard approved as
_the_ Lua approved way of doing it would encourage people to write modules.
After all, we can all add this to our interpreters, but unless people
actually produce modules in this fashion it means nothing.

I understand the desire to keep the Lua code platform independent; but I
cannot help but think this will limit the acceptance of this as a standard
if it doesn't work in a standard Lua binary.  Getting people to accept Lua
is already hard enough, and saying you have to download this other package
with loadmodule() support for each platform then re-build Lua before you can
test with module xyz is not much worse than saying you have to statically
link xyz.

Nonetheless, either way this is a vital standard to have in place; I am
finding it increasingly difficult to answer user questions on whether they
can do feature X in Lua, because it means I have to find and link
appropriate code in, which is almost never for the right version of Lua, and
not always under a clear license regarding commercial use.  At least
loadable modules would be directly available to end users, and as such the
licensing is not my concern with each and every one.


Perhaps my situation is a little different from most Lua users;  in my case
the 'end-user' does not imply some other programmer who is using an embedded
Lua to create internal scripting, but the actual end-user of our
application.  These people are not programmers, or even technical in many
cases, yet most of them can manage a little scripting (some more than
others).

It is with these people in mind that I must consider any extension
mechanism; and this makes it important that such a system does exist (it is
impossible for these people to link static modules with the application, as
has been suggested as being adequate for extensions).  I can understand this
rationale in embedded O/S applications, or even internal scripting, but it
simply does not work in a user-accessible scripting system.

So I am very keen to have this work as a standard, and work simply.

Thanks!


Love, Light and Peace,
- Peter Loveday
Director of Development, eyeon Software