Re: Should tiny utilities be prepackaged?

[Philipp Janda <siffiejoe@...>]

Am 01.03.2016 um 19:21 schröbte Sean Conner:
> [...]
>
>    Because that way lies madness.  For instance, table.copy().  Is it a
> shallow copy?  A deep copy?  How are cycles handled?  If the same table
> appears twice (but not in a cycle), is each one copied?  Or one copied and
> the other a reference?  There's no one solution.
I once saw a talk by a C++ guy about <algorithm>s. He said that you'd 
want a whole collection of variants of basic algorithms (he specifically 
mentioned `copy_if`), because those are the algorithms that you will 
most likely need. I think I agree with him, and so I would actually like 
to see a specialized `table.copy` module that includes the most common 
ways you'd want a table copied plus maybe a modular way to get a copy 
function tailored to your specific needs (Please, module, give me a 
function that does a copy two levels deep, handles metatables, and calls 
a `__copy` metamethod when it encounters a userdata, but I don't expect 
any cyclic references!).
> > 3. Should we make any attempt to standardize the name and
> > functionality of such routines, in the hope that one day a Lua
> > standard library, widely accepted by the community, will emerge?
> Mu.
I think it's already happening. This is list of modules I consider Lua's 
extended standard library (in the order they are mentioned on the Lua 
Toolbox):
*   luafilesystem
*   luasocket
*   lpeg
*   luaexpat
*   semver
*   vararg
*   luasql
*   lrexlib

All listed modules are portable (some as portable as Lua, but most of 
them run at least on the three major desktop OSes and the last three Lua 
versions). They are comprehensive and useful to more people than just 
the original author. They have a clear focus. They are as general as 
possible (lxp.lom is an exception). They have won against competing 
modules (not sure about luasql vs. luadbi, though). And they are more or 
less maintained.
But I think Dirk was talking about utility libraries. In that case I 
think we will probably never get a universally accepted standard, 
because what is useful depends on your taste and style of programming. I 
believe knowing a function name and the module it is in, what it does, 
what parameters it takes, and what values it returns (or looking all 
those things up) is more trouble than writing five lines of Lua code. So 
the existing utility libraries for the most part are too specialized and 
bloated for my taste.
What I would find interesting is a more scientific approach of choosing 
functions for a utility library: Scan publicly available Lua code from 
different authors, collect domain-independent functions that are used 
more than once, and take the top 30 (or so). Personally, I'd then try to 
merge as many functions as possible to reduce the number even further, 
even if that means that I'd have to write one or two more lines of Lua 
code to achieve the original effect (as I said, I like a small number of 
versatile functions rather than a large number of specialized ones).
> > 3a. Should libraries like stdlib, Penlight and org.conman make
> > any effort to become compatible in terms of naming and
> > functionality?
That would mean that I'll never find a utility library that I will like. 
And if they are basically the same, we can get rid of one or the other. 
I think that as long as there isn't a clear winner, neither should be 
considered part of a standard. However, if the authors of Penlight and 
stdlib were able to merge the important features (and I don't mean 
individual functions here) of both libraries into one without adding too 
much bloat, *that* would be interesting.

Philipp