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

[Jamie W. <j...@jm...>]

On Wednesday 04 February 2004 10:58, Reuben Thomas wrote:
> > 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).

I'm wondering though if the special-purpose stuff wouldn't be better going 
straight into Cheia rather than stdlib.

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

Perhaps some metrics on level of usage of each function would be more 
appropriate.

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

I agree.

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

Mmm... except that most of what is in Lua table ought to be in vector.

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

Well, fn or something rather than function presumably. Given the argument 
order, the existing convention suggests that map and filter ought to be in 
function. Trouble with that is that then you can't have vector.map, list.map, 
table.map, etc. So, either the argument order needs changing (bad, because 
other languages have it that way round, and it makes the most sense for 
partial applicaton), the convention needs abandoning (might be bad, depending 
on this whole { __index = table } business), or map needs to be on vectors 
only (bad; not very forward-thinking).

 -- Jamie Webb