Re: Should tiny utilities be prepackaged?

[Sean Conner <sean@...>]

It was thus said that the Great Dirk Laurie once stated:
> <boringalert> I'm returning to a topic that has been well chewed
> over on this list many times.
> </boringalert>
> 
> Many if not all of us have small, almost trivial utilities that we include
> in most of our programs. Here is one of mine. It is given only to focus
> the discussion, not because I think it is in any way unusually good.
> 
> local clone
> clone = function(tbl)
>   if type(tbl) ~= 'table' then return tbl end
>   local t={}
>   for k,v in pairs(tbl) do t[k]=clone(v) end
>   return t
> end
> 
> Please do not point out particular defects of the code, such as that
> the original table may have had duplicate subtables but the clone
> does not. It is given _only to focus the discussion_, as an example
> of the size and nature of the little utilities that I am talking about.
> 
> The questions that IMO bear revisiting every now and then are:
> 
> 1. Is it a good thing for a newbie to write such utilities from scratch,
> in the process learning some subtleties of Lua, rather than grab
> them off a standardish package? (Niklaus Wirth omitted an
> exponentiation operator from Pascal for mainly this reason).

  Yes.

> 2. Should the Lua standard libraries supply any non-basic table
> routines?

  No.

> 2a. (This is a specific version of the previous point.) Why do you
> think did the Lua team supply none such beyond `pairs` and
> a library that operates on sequences?

  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.

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

> 3a. Should libraries like stdlib, Penlight and org.conman make
> any effort to become compatible in terms of naming and
> functionality?

  Having taken a quick glance at Penlight and stdlib (neither which I use),
org.conman has more in common with luasocket and lusposix than Penlight or
stdlib.  With that said, I'm in favor of making the libraries compatible
only if everybody follows my lead (because all'y'all are doing it wrong! 
Wrong I say!  Wrong!).  Otherwise, no.

  -spc (If I wanted to program to a C API, I'd be using C ... )