Re: Batteries

[Dibyendu Majumdar <mobile@...>]

On 11 March 2018 at 14:53, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 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.
>

If you think deciding which libraries to include, setting standards
for inclusion, testing that the libraries work, is administration then
this whole discussion is a non-starter and idle talk, as existing
distros already do the rest. My suggestion above was to avoid
burdening the Lua team but put the onus on the community leaders (who
are these?).

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

Sure and possibly nothing will come of it as from past discussions.
But times are changing .... Lua's trajectory is flat line whereas
other languages are growing in importance. Here is a thought
experiment: what if Mike Pall had decided to not drop LuaJIT and had
decided to actually enhance the language in a different direction and
created a larger set of libraries for it. What do you think would have
happened?

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

I am spending a lot of time testing and fixing issues ... you need to
have this if you want a quality / reliable set of libraries.

> 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 do think it needs more effort if it is to be any success.

Regards
Dibyendu