Re: Zoom out

[Roberto Ierusalimschy <rieru@...>]

My personal suggestions for the future of Lua libraries:

1) we should add a "loadlib" facility to the "core" of Lua. This is
non-ANSI C, so its inclusion should be controled by a simple define in
the makefile. This function must be in the core (like `require'), to
enable an out-of-the-box Lua instalation to use any external libraries
without recompilation.

2) because loadlib is written in non-ANSI C and is in the core of Lua,
it should be as simple as possible. That is why I advocate the use of
an auxiliar Lua file for each C library. This Lua file (that must live
in LUA_PATH, to be loaded with require) can specify the path to the C
library, select library versions based on Lua version (using _VERSION),
and whatever else that can be done in Lua. Moreover, with this Lua
file, users can always `require' a library, without worring whether the
library is written in C or in Lua (or in both).

More specifically, I think loadlib should provide:

  - loadlib(complete lib-path, init function)
  * loads the dynamic library at "complete lib-path" (something like
    /local/lib/lua/xuxu.so), and calls "init function" to initialize
    the library. (If there is a pattern that specifies the "init function"
    name given the library name, let Lua do it.)

  - _UNAME
  * a global variable that specifies the platform, so that a Lua file can
    choose where/what to load.

3) on top of that, libraries should use some form of modules (all public
functions in a table, for instance) to control name-space polution. There
is no need that all libraries use the same scheme (altough it would be
desirable).


Most other problems (like how to unload libraries) do not seem to be of
general importance. Let us wait for the real problems before solving
them.

-- Roberto