Re: Bugs.. ? (was: Re: Lua-users standard libraries project: anyone game?)

[Thatcher Ulrich <tu@...>]

On Jan 28, 2004 at 09:37 +0100, Reuben Thomas wrote:
> > Hmm... begin to see a pattern here.. I miss the coresponding c libs
> > needed (like bits and rex etc). Maybe the lib should check wheter these
> > libraries are available or not, before doing their stuff :)
> 
> Yes, that's true. I should put in a test, and have now. It's a while since
> I thought about it, but I think the reason I didn't do anything was that
> it's not entirely obvious what my approach should be if the library isn't
> loaded. Should I complain? Silently fail to compile the requisite
> functions? Load them anyway (but they won't work unless/until you load the
> C part)? And what about extensions to the standard C libraries (table,
> string &c.)? What if they're not there?
> 
> For the moment, I've made the loading of std.bit and std.rex conditional
> on the existence of tables bit and rex *in std.lua*. So if you say
> require "std" and you are lacking bit or rex, it won't complain, but if
> you say require "std.bit" and you don't have bit, you'll get the error you
> just got. That's the simplest solution I can think of that definitely
> improves what I have at the moment.
> 
> I'd be interested to hear ideas on solving the more general problem. I
> guess this is something that has to be solved for integration into
> LuaCheia.

What we typically have been doing in luacheia is something simple like
this:

assert(cheia.load("bit"))  -- if it's already loaded, this is a no-op
assert(cheia.load("rex"))

-- ...code using bit and rex here...

Obviously that's luacheia-specific, doesn't do any versioning, and
throws an error if the libraries can't be loaded.  I think throwing an
error is a good default policy; for certain cases it might be
desirable to have a fallback instead, which is straightforward to
check for:

if not cheia.load("bit") then
   -- fallback
end
-- etc

I'm not sure of the right way to do this in a distro-neutral way.  We
could imagine a more generic-sounding loader function, e.g.:

function std.load(module)
	-- distro-specific stuff in here...
	if cheia and cheia.load then return cheia.load(module) end
	-- ... other ways of loading ...

	-- perhaps also check module against a list of statically
	-- linked modules

	return false, "we have no method of loading modules"
end

As far as namespaces go, we have been using a single-level namespace.
Modules are certainly not prohibited from defining their own
sub-namespaces, but cheia.load() and the like don't understand
hierarchies themselves.  E.g.:

cheia.load("std")	 -- OK
cheia.load("std.bit")	 -- not understood in a meaningful way

We originally had a configurable, hierarchical organization, but it
created all kinds of headaches, and seemed to offer little gains.  One
of the bigger headache is that luaL_openlib() expects a global table
name, so supporting sub-namespaces in other people's libraries
involved grafting in a bunch of external code.

So the policy is that module tables live in the global table.

-- 
Thatcher Ulrich
http://tulrich.com