On Fri, Dec 18, 2009 at 12:52 PM, steve donovan
> imap [...] takes an arbitrary
> number of tables, and therefore supercedes map, map2, map3 etc.
This does sound interesting, I will check imap out. Are there are any
efficiency compromises involved with an arbitrary number of tables?
There's a shortcut for the most common case where there's only one argument. For cases with several tables and/or explicit boundaries, it keeps as much stuff out of the loop as possible. The only significant additional cost in loop is the accumulation of function arguments in a list, which is the equivalent of a just-in-time zip. I don't see a way to get rid of it without using C.
By 'recycles the i of ipairs/pairs convention' do you mean that the
function is passed both the value and the key, in that order?
No, it doesn't pass the key at all for "ixxx" versions:
- most of the time you don't need it;
- when passed, they give a clumsy, non-functional feel to the code;
- in the few cases where you do it's easy to work around it.
It only passes keys for hashtable-oriented functions.
> zip2 = |t1, t2| table.imap(|x,y| {x, y}, t1, t2)
Ah, such nice notation ... alas, it is not to be ;)
:)
