Re: More about packaging (hopefully not too long)

[RLake@...]

> 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.

Rici

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
understand.) 

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
:)