Re: LoadLib 5.1 problems and concerns

["Timm S. Mueller" <tmueller@...>]

On Mon, 09 May 2005 20:56:33 -0300
Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

> > - On platforms without dynamic library loading capabilities, not only
> > the "loadlib" function gets disabled, but also "require". The mere
> > presence of the C loader voids the functionality of the entire Loadlib.
> > This is probably a bug.
> 
> Can you give more details? I could not reproduce that behavior.

At the moment I can't reproduce it either. When I stumbled across the
alleged problem, I was probably mixing different things up badly. Sorry.
 
> > Even though the definition for the path delimiter can be overridden,
> > I think that Lua should not try to abstract from an underlying
> > filesystem in any way -- this task should be left to specialized
> > third-party libraries. It seems more appropriate to me if at least
> > one function (preferrably "require") is guaranteed to leave the path
> > and filename unmodified.
> 
> One of the main uses of require is to search for modules. So it cannot
> leave the path unmodified. There is one function that leaves all
> untouched: loadfile. Actually, you can use it together with require (but
> don't have to):
> 
>   package.preload["modname"] = loadfile("/whole/path/myfile.lua")
>   require"modname"

Loadfile itself is no replacement for require, but this is slick! I can
live with that. The problem is that the previous behavior (and the
documentation) did not contain a hint towards a special meaning of the
dot character. This renders some of my old scripts incompatible.

A different approach would be to present Lua an uniform filesystem
namespace, regardless of the operating system underneath, and to use
a path delimiter where a path delimiter was meant. This is the idea
I'm pursuing, by providing replacements for functions such as fopen and
dlopen. At present it's rather unrealistic for this approach to become
part of the main development branch of Lua, I guess; what I'm asking for
is to make as few assumptions about the underlying filesystem as
possible, and not to introduce new meanings for characters too easily.

- Timm