Re: Batteries

[Dirk Laurie <dirk.laurie@...>]

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.