lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> I'll comment on Rici's post here. It seems like an unnecessary complication to
> require that Lua code be embedded in a library in order to create combined
> libraries.

I agree. It shouldn't be a requirement for the system to work. However, it
is a possibility and I think it is much cleaner for a production distribution,
particularly for those of us who like to deploy single statically-linked
Lua executables.

The advantage of "require" working identically with either Lua or foreign
libraries is that both modes are possible without editing user programs.

Similarly, requiring Lua stubs to exist for every C library also seems
to me an unnecessary complication, both for users and for packagers.

> Actually, I've just convinced myself that the import function
> should not exist at all.

By the way, although I agree that "import" is not something I would use,
I gave a one-liner for it:

  function import(name) _G[name] = require(name) end

so anyone who wanted that behaviour could easily get it. It is worth
thinking about the complexities introduced by setfenv(), though --
replacing _G with getfenv() in the above would mean that the module
was imported into import()'s environment table, quite possibly not
what was expected. It is for this reason, amongst others, that I
think "automatic globals" are a bad idea.


PD: Path searching is a pain. However, it has proven its value over
the years and alternative systems rarely work as well. (Consider the
number of people who have been caught out by ldconfig, for example.)
Caches are notoriously difficult to get right. Built-in paths seem to
be difficult to document (and therefore for non-sophisticated users to

Having said that, the sample code I provided yesterday, which uses
module instantiation functions as an intermediate representation,
is a surprisingly powerful model. It allows the detailed loading
procedure to be abstracted into an single function; require() does
not need to know where the mod.inst.func comes from, it just needs
to run it.

The actual code I use for sandboxing takes advantage of this; setting
up a table of instantiation functions for a sandbox is simpler than
coming up with an OS-independent way of checking the validity of
file paths. In addition, it makes it easier to do things like load
modules over networks, or from comressed archives, etc.

The fact that Lua deals so cleanly with functional objects and closures
provides possibilities which should not be overlooked :)