Re: Batteries

[Marc Balmer <marc@...>]

> Am 11.03.2018 um 16:13 schrieb Dibyendu Majumdar <mobile@majumdar.org.uk>:
> 
> 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

That is your opinion only. FUD.

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

What do you think would have happened if god the almighty (does he even exist?) created three sexes instead of only two?  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