Re: Standard Libraries: (was: and Lua marches on)

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

On Thu, Dec 17, 2009 at 12:43 PM, Luiz Henrique de Figueiredo
<lhf@tecgraf.puc-rio.br> wrote:
>> the dual nature of Lua tables makes defining the basic map, filter etc
>> primitives an interesting challenge.
>
> Why?

Well, they are classically defined for ordered lists.  A simple map()
function would do fine for either array-like or hash-like tables,
since the actual order of iteration is not ultimately important, since
we use the keys of the source.  But the trouble comes with tables
which are (say) primarily array-like, but have some hash entries as
well; then you define imap() with ipairs to insist on only operating
on the array part. It would be straightforward (and useful) to define
a function which only copies the array part of a table,and then use
map(), but that strikes me as an inefficient implementation of imap,
because of the temporary copy made.

Or one could be hard-line about it (as table.concat does) and insist
that the tables are either one kind or the other kind.

One could also be explicit about the iterator factory used, like
map(pairs,fun,t). This feels more Lua-ish, since there is no ambiguity
about how the key/values are iterated and there are opportunities for
interesting generalizations.

steve d.