Re: stdlua.lua

[Reuben Thomas <rrt@...>]

> 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
   people submit.

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
   natural way:

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
C).

> 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
StandardLibraryProposal page.

> 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
> appropriate).

Seems good.

> 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