Re: Project lead nominations for standard libraries?

[Mark Hamburg <mark@...>]

Having kicked this off, here is what I would like to see. It's entirely legitimate to criticize me for not then stepping up and driving this, but there it is...

1. For issues like # v holes, I think we need a reasonably sized increase in the standard facilities within Lua. I'm thinking on the order of at most doubling the set of standard functionality. For that matter, if backwards compatibility could be tossed aside, I would replace the table namespace with an array namespace that supports a data structure (built using tables and/or userdata) that is "hole" friendly which would keep the library almost identically sized. There are a lot of people who are going to start with the stock libraries in the language and if those could evolve a bit to resolve some of the routine grumbling, I think that would be a good thing.

2. I think a facility like Lua Rocks could handle most of the other needs if there were a standard repository where people could go looking for functionality and could find reviews and commentary on the various rocks found there. (Okay. It might also help if there were more documentation on how to use rocks viably within projects. A lot of Lua implementations are embedded and making it clear that if you pull the SMTP rock and the sockets rock, you plug them into your embedded implementation in the following way.)

The first item needs a designer and a dictator and ideally buy in from the Lua team since otherwise it involves making available and promoting a separate core distribution. The second item can be much more freeform and open, but needs a strong community feedback mechanism to help people new to Lua (and even old hands pursuing new areas) sort the wheat from the chaff.

Mark