Re: [Lua-users-stdlib] Upheaval (blame Jamie Webb!)

[Reuben T. <rr...@sc...>]

> Seriously though, I realise it's not very general, but I have found it
> useful.  I suppose it just depends on how large you want the library to
> end up.

That's a difficult question, of course: we have multiple goals. First, to
reach into and improve the libraries actually shipped with Lua. Secondly,
to add some core programming utils (this is mostly what we've discussed so
far). Thirdly, to add lots of special purpose stuff (like Diego's mbox
parser, which I was eulogising last night).

So far I've not really separated 1 and 2 (in a sense they shouldn't be,
because both are aiming at the goal of providing an improved standard
library that is actually shipped, or at least in our view should be
shipped, with the standard distribution).

However, it's easy to tell the difference between 1+2 and 3 (if you'll
forgive the pun): code for 1 & 2 have mostly been put in modules with the
same names as the existing C libraries, and the rest has gone in special
modules.

I've already removed some of my functions that I haven't used much or at
all; I think the first thing to do should be to try to find an optimum
"shape" for the core stuff. Options include

  1 Inventing a new "core" library and simply keeping it as small as
    possible (perhaps setting a hard limit on number of lines of code,
    which may sound silly, but could be helpful in focussing the mind on
    what's important)

  2 Putting everything strictly in table & string; this doesn't really
    work, because a lot of stuff we have is really to do with functions,
    not tables.

  3 Adding a few new libraries as necessary. For example, I propose to
    abolish my set module, folding it back into table, but adding a vector
    module is arguably good.

I'll end with a concrete proposal of what I think is best from the above:
we should add "vector" and "function" to the current "string", "table"
&c., and put all our additions into those four tables. One or two are
tricky (are map and filter in function or table?) but they all fit in one
of the four. Once that's done we can take another look.

> method() is to methods what bind() is to functions (bind_method() lies
> somewhere in the middle). I don't see how you can claim that one is useful
> but not the other. Personally, I use them both about equally, and from my
> libary use only map() more frequently.

Fair enough. Arguments like this are difficult to resolve until we've had
more experience with a larger community of programs and more lines of
code. There's scope for a little bloat in the interests of variety to
start with in the library as long as it's understood that it should get
smaller (in the core), not bigger. I don't think there's much of a problem
with outlying modules getting bigger.

Of course, this is always going to be the stuff that people argue over the
most, too.

-- 
http://www.mupsych.org/~rrt/ | golf, n.  a good walk spoiled (Twain)