[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: stdlua.lua
- From: Reuben Thomas <rrt@...>
- Date: Thu, 27 Sep 2001 15:19:45 +0100
> Excellent idea, I suppose a lot of people already have a toolbox of small
> Lua snippets and utilities.
The process could go something like this:
1. Assemble a large file that is simply catted together from whatever
2. Someone (or people) can sort (or filter) it into categories: text
processing, data structures &c.
3. As a result, we hopefully obtain a series of modules.
Ideas about naming:
1. Have a hierarchic name space.
2. Call the top of the hierarchy "std".
3. (Possibly contentious): I think it's worth adding a function so
that you can allow bits of the hierarchy to be included in a
import("std") -- get the whole thing; the easy option for most scripts
import("std.data") -- get the data structures routines
import("std.io.socket.tcp") -- if you're being disciplined, and
-- perhaps developing a large project, it might be nice to import at a
-- fine granularity
It might be nice to be able to say
open("std.io.socket.tcp") too, to lift a namespace to the top level,
in a particular module.
You could set things up so that require("std") also gets the whole
thing (i.e. you don't need import).
Without getting too far off track, one useful thing this library
scheme could add to the base Lua system is the ability to bind Lua
libraries into a system in the same way as C libraries, so it's
available at startup; then, the entirety of "std" could be made
available by default (since it would all be under the "std" table,
this shouldn't be a problem). This would allow us to make standard
library available more easily (no need to load it) and flexibly (use
new functions like "import" and "open" without having to write them in
> You should propose a base file, so we can start to throw in functions
> respecting your specification.
I've uploaded my util library (which James Hearn pointed out my GetOpt
library needed in any case) to the Lua-Users Wiki, and have started a
> I propose to start by putting, among other things, some routines
> from the test folder (savevar is a good candidate), and lot of code
> from Roberto's book (the DumpString, as I sent to the list, seems
> For the "obvious" code, taking only 2 or 3 lines, like the
> test/qp.lua (convert quoted-printable encoded string), it should be
> put in a kind of FAQ or snippet repository. The wiki is of course a
> good place for this.
I think the "obvious" code should be included in the library; no point
in having to work out 2 or 3 lines if it can be encapsulated as a
useful and reusable function.
http://sc3d.org/rrt/ | egrep, n. a bird that debugs bison