Re: [ANN] Penlight Libraries, First release

[steve donovan <steve.j.donovan@...>]

On Thu, May 14, 2009 at 4:10 AM, David Manura <dm.lua@math2.org> wrote:
> That breaks a bit from table.remove, which returns the element removed
> (semantically somewhat like pop).

Point taken.

>  filter and remove might be dual
> things in that remove returns the element discarded, while filter
> returns the elements kept.

That makes sense, especially if filter always operates in-place. In
fact, List.map/map2 should operate in-place as well, and then the only
exceptions are explicit slices.  Then tablex.imap and List.map have
different semantics.

List.pop has the same semantics as table.remove, if passed an
arbitrary index (default is the last index).

List.remove_value currently assumes that the value is comparable with
==, in which case we are probably not that interested in the result.
But if it could take an optional predicate, then the removed value
could be useful.  Also, if the predicate returned two values, then the
second value could mean 'keep going'

ls:remove_value(function(x)
   if cmp(x,val) then return true,true
end)

which results in all elements matching cmp being removed. But then if
it returns the discarded values, they have to be a list.

I'm still not sure, because people might want to use List.remove_value
as part of a method chain.

> tinsertvalues(t, [pos,] t2)
> It takes a form similar to table.insert(t, [pos,] v), except that it
> inserts all elements of v rather than v itself.

I like that, a good candidate for tablex. Currently List.splice (name
comes from C++'s std::list) does this, although uses table.insert.

The overriding principles are these: can a function's purpose be
clearly stated in a line or two, without surprise? Are we providing
enough basic primitives that common operations can be expressed
clearly?  Are the names self-consistent, and consistent with
established Lua conventions?

steve d.