Re: Lua libraries workshop scheduled for Feb 19

[Reuben Thomas <rrt@...>]

As another non-attender, here are some initial thoughts:

There are two main reasons to write Lua libraries in C: efficiency (mostly
speed, perhaps also memory usage from time to time) or functionality
(accessing existing C functionality that would be impractical or
uneconomic to replicate in Lua).

As far as the standard libraries go, the requirement of pure ANSIness
means that only ANSI C functionality can be provided. I would suggest that
unless there are good efficiency reasons to do otherwise, it's best just
to expose the C API to Lua as directly as possible (as the current
libraries tend to); further layers of abstraction can then be added in
Lua. In other words, there's not a lot wrong with the math, I/O or system
libraries.

The basic and debug libraries are also about adding functionality, but
here in a different way: they primarily reflect the functionality of the
Lua C API back into the language. The same rule as above should apply:
unless there are good (probably efficiency) reasons, they should do no
more than mirror the C API into Lua. This is pretty much what happens at
present.

The string library is different: it does provide functionality, but a
large part of its utility is in its pattern matching, which gives much
better performance than anything that could be written in Lua. Experience
has shown it to be extremely effective; even the omission of alternation,
which might seem a glaring flaw to the regexp enthusiast, is largely
offset by the ability to pass a function argument to gsub for
replacements.

In the light of this, here's what I'd look at:

1. Is it possible to expose more of Lua's internals as libraries?

In particular, it'd be really nice to be able to get at the internals of
the compilation process, e.g. to be able to manipulate code as data
(rather than resorting to string mangling as at present). Similarly, see
my past proposals on the list about being able to plug in a different
regexp engine or (more controversially) garbage collector.

2. What about reimplementing some of the standard libraries in Lua?

Some functions, like assert, could easily be implemented in Lua, and
implementing them in C gives little or no advantage. In addition, there
are functions written in Lua that it is most useful to add pre-loaded to
the interpreter, e.g. require (to 4.0). Having a framework to build Lua
libraries into the executable would be easy (bin2c already does the work)
and useful. Reducing the amount of code written in C would improve
usability and reduce maintenance.

3. What else is needed?

As far as the standard libraries go, this reduces to the small question of
whether there are any missing bits of the ANSI C libraries that can
usefully be exposed to Lua, and the rather bigger question of whether
there are any techniques that, like pattern matching, would both benefit
from a C implementation and be widely used. The only (pure ANSI)
functionality I've ever needed to add has been bitwise logical operations
(my library for this is widely packaged, so others seem to agree).

Finally, an obvious next step if you accept the argument that as little as
possible should be written in C is:

4. What about Lua standard libraries written in Lua?

I'll say only that this is a can of worms worth opening.

-- 
http://sc3d.org/rrt/
L'art des vers est de transformer en beautés les faiblesses (Aragon)