Re: Lua library bank?

[David Heiko Kolf <kolf@...>]

Dirk Laurie wrote:
> Do we really need another library bank? We have luarocks.
> It's a pons asinorum. Packaging something as a rock is just tricky
> enough to eliminate the nine-day wonders and let through only
> those authors with a little staying power.

In my opinion even the libraries in LuaRocks are not all high quality.
And to me that is one of the problems in the Lua universe.  The Lua
interpreter is really high quality, but I am often not satisfied by many
of the libraries.

So I would prefer a standard library where all the code follows some
coding style document, that gives general advice on how to write a good
C module or a good Lua module.

A few examples of what I am usually following:

- I do not keep global state in a C module, but store everything in the
Lua state (in the registry or in C function upvalues).  (Of course, only
as far as it is possible with regard to the library I am binding to).

- I avoid standard "malloc"/"free", instead I use userdata even for
internal memory. When writing a binding to a foreign library I of course
also use whatever the library expects me to use.

- I try to not keep pointers to userdata after the userdata left the
stack but assume a "moving garbage collecter" where the position of the
memory might change -- even though Lua does not have this.  Instead I
load the userdata from the registry or the uservalue table of another
userdata every time I need it.  It might be a bit slower but it should
also avoid dangling pointers and make sure that everything that is still
used is also referenced in Lua.  (And who knows whether some future
implementation is including a moving GC...)

- I make sure that I write finalizers for any foreign resources.  Even
if I just use them internally, when I am worried that Lua errors might
interrupt my standard program flow.

- I don't write to global Lua variables.  When a function is intended to
write to global variables, I give it a parameter for the global table so
the user would write "lib.registerstuff(_G)".  That also makes it easier
to use the library functions in a sandbox.  Even the module table itself
is by default not saved in a global variable but just returned by the
module.

- I try to keep my Lua modules as compact as possible and keep them in
one .lua file.  I know it is subjective, but to me it is hard to read
when tiny subtasks are all put into different files.  And it makes it
quite a task to rename a module or to include it in a system where
"require"/"module" or a directory system do not exist.

- Even more subjective and hard to define, but a module should show some
"Lua-style".  Sometimes I see a module and it looks to me like raw C
bindings and I keep thinking that the API might be a lot simpler in Lua.

This are just a few points that came to my mind.  If a standard library
is really built, even such cosmetic things like indention should be
defined to give it a uniform look.  Here I would mimic the style of the
Lua implementation itself.

Dependencies are also an important point, how easy is it to build the
module.  Is the foreign library already included in the sources and
ready to compile with a single command?

Just some thoughts that came to my mind on the topic of (standard)
libraries for Lua.

Best regards,

David Kolf