Re: Batteries

[Marc Balmer <marc@...>]

> Am 11.03.2018 um 15:53 schrieb Dirk Laurie <dirk.laurie@gmail.com>:
> 
> 2018-03-11 13:10 GMT+02:00 Dibyendu Majumdar <mobile@majumdar.org.uk>:
>> On 11 March 2018 at 08:25, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>>> 2018-03-11 3:42 GMT+02:00 Dibyendu Majumdar <mobile@majumdar.org.uk>:
>>> 
>>>> On the other hand, I think this model is harmful for the 'batteries'
>>>> part - which could easily be improved by allowing external
>>>> contributors.
>>> 
>>> I use Roberto's LPeg and several of Luiz's modules: complex numbers,
>>> C99 math, XML parsing etc. They are of comparable quality to Lua
>>> itself and stay abreast of new releases, but they give a glimpse of
>>> what Lua might have been like if developed by only that person ­— and
>>> I wonder if Waldemar's unheralded role might not be to mediate between
>>> two extremes.
>>> 
>>> The key is: "of comparable quality to Lua itself ".
>>> 
>>> We have two main battery providers: stdlib and penlight, and one
>>> battery compiler: luarocks. Will lovers of the first two please stand
>>> up to be counted? I use a dozen or so offerings from the third, but
>>> with caution: there are often several different offerings for the same
>>> task, and they come without quality certificates.
>>> 
>> 
>> Sorry I don't think I explained clearly what I meant.
>> 
>> The Lua core libraries are constrained by the need to be small,
>> portable anywhere there is a C99 compiler, hence most libraries cannot
>> be included in Lua standard library.
>> 
>> However, the community needs and would benefit from an extended
>> standard library that is supervised / blessed by the Lua team. All the
>> Lua team have to do is:
>> 
>> a) Create an official repository - perhaps in Github
>> b) Appoint trusted leads who can manage the library - I am sure many
>> people here who maintain distros or major libraries would be willing
>> to help - I can think of a few names including yours.
> I am allergic to anything that smacks of administration.
> 
>> c) Take part in regular reviews and decision making - maybe spend 1
>> hour per fortnight in an online meeting to approve / disapprove
>> decisions taken by the leads.
>> d) The leads should create a shortlist of the libraries that need to
>> be include - and set criteria on quality, documentation, portability
>> etc., again possibly reviewed/approved by Lua team.
>> 
>> All this can be done with very little effort from the Lua team.
> 
> In 24 years they have never been willing to canonize. Why suddenly now?
> 
> The only way to achieve am extended standard library would be for one
> or two dedicated persons to say "these are the modules we personally
> use regularly and we take the responsibilty for keeping them
> compatible with the current Lua release from PUC-Rio". Such as you
> seem to be doing with your latest effort to make libraries that you
> support for Ravi available for Lua 5.3 too.
> 
> All that the Lua team need help us with is some infrastructure.
> 
> 1. Agreement that a `contrib` directory in the standard distribution
> is reserved for modules for an extended standard library.
> 2. (Optional) Seed that directory with LPeg and some of LHF's
> libraries. No need to go outside the Lua team here.
> 3. Modifying the standard Makefile so that `make SYSTEM contrib`
> builds modules in `contrib` and `make install` installs them.
> 
> Then anybody who has a module that they think is a candidate of the
> extended standard library must supply it a zip, tgz etc archive, to be
> extracted when in the root library of the Lua distribution, that will
> build out of the box that way.
> 
> The only administration needed will be to draw up a jealously guarded
> list of names of approved modules. I say "only", but this will be the
> crunch.

I truly love Lua the way it is.