Re: Standard Libraries:

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

On Fri, Dec 18, 2009 at 5:22 PM, Doug Rogers
<doug.rogers@elbitsystems-us.com> wrote:
> Can it be both? If the argument is a function, treat it as an iterator.
> If it is a table, treat it as a list. If it is a userdata... uh, try
> indexing [1] and if it works, treat it as a table, otherwise try __call?

Well, certainly we need a short form: if it just worked with
iterators, then the very common operation of transforming a table
would be something like this:

keymap(map(fun,ipairs(t)))

(where keymap is an adapter that makes a table out of a two-valued sequence)

Now, to elaborate, you are suggesting that map(fun,t) can return
either a iterator or a table, depending on the type of t.

i.e. map(tonumber,{'10','20'}) -> {10,20}

for f in map(string.lower,lfs.dir '.') do ... end

I quite like that, but the devil is in the details; a function is
obviously a sequence, and a plain table is a list (but hash?).  Then
things get complicated; ok, it's got __call, treat it as a function.
But indexable userdata with __len is clearly meant to be an array,
that takes precedence.  So, the description of type t gets involved;
the key exercise here is trying to explain what map does ;)

So map/map_iter is the simplest.

There are some advantages to this 'smart' map, because you could write
code that did not particularly care whether it was passed an iterator
or a table, but then the rest of the library would have to be
consistent with this.

> Or dare I bring up __iter for userdata? :)
Why not, but it might get people sidetracked ;) __pairs/__ipairs is a safer bet.

steve d.