Re: "formula" short anonymous func

[spir <denis.spir@...>]

steve donovan dixit:

> On Fri, Dec 25, 2009 at 1:28 PM, spir <denis.spir@free.fr> wrote:
> > This is an attempt at solving the here often debated issue of short anonymous funcs such as
> >    x --> x * x
> >    function(x) return x * x end
> > in a simplistic manner, in the case where a single variable is in play. This is rather intended to be used in higher-order funcs such as map or filter.
> 
> I liked this way of doing things, but David M has pointed out that
> making the function argument of map, etc to be a special string is a
> problem for two reasons:
> (1) A person may make their strings directly callable, by setting
> getmetatable("").__call.
> (2) It is implicit behaviour and makes these functions harder to
> describe precisely.
> 
> So by the 'be explicit in Lua' principle, you would call formula directly:
> 
> t = map(t,formula "_*_")

Yes, you are right. And I'm also fan of expliciteness as much as possible. But; if we want to express the call to formula in higher-order func calls, then the gain (both in compactness and clarity) is minimal. Rather express the func itself:
    t = map(t, "_*_")
    t = map(t, formula "_*_")
    t = map(t, function(x) return x*x end)
I mean the gain in clarity is minimal because the formula syntax is not standard.

> (BTW, what precisely is the default character given? It appears to be 0xA4?)

'¤' is the "currency sign" (supposed to be used when actual currency is not available) (happens to be on fr-FR keyboards on same key as £ & $). Precisely chose it because it _never_ appears anywhere ;-)

> We can go a little further, and allow for strings like '_1*_2' meaning
> function(x,y) return x*y end.
> 
> As for the order of map() arguments. I originally defined them as
> (table,function) in the first iteration of Penlight (it felt natural
> to put the function last), but was persuaded that the 'canonical'
> order is (function,table).
> 
> Maybe we should reconsider this, since all
> of the table functions have the table as first argument, i.e. as the
> 'self' parameter.

I think the "canonical" order is wrong. The _object_ of the process is the item sequence. IMO, your first throw was right (and legacy can be wrong!).

>  Consider this entertaining little trick:
> 
> local TMT = {__index = table}
> 
> function table.new(t) return setmetatable(t,TMT) end
> 
> local T = table.new  -- alias
> t = T{'one','two'}
> print(t:concat())
> =>
> one,two
> 
> (There have been questions about why this isn't the default state of
> newly created tables, but it's better to make this explicit)
> 
> Now, if map, filter etc consistently have the table as the self
> argument, then things work as expected, e.g. t:map(string.upper).

precisely what I mean above

> However, this argument order means that map() takes precisely one
> table argument, so you can't do the generalization-to-n-tables (map2
> etc) which Fabien has in his version of table.imap in the Metalua
> libraries.

If I understand correctly (*), then the first argument of "map_more" should be a sequence of sequences. That's what it conceptually is, IMO:
    row_sums = map_more({col1,col2,col3}, sum)
Another solution is to apply a kind of python zip to get a sequence of tuples.
    row_sums = map(zip{col1,col2,col3}, sum)

Or clearer, through proper naming, even if it costs a line of code:
    row_sums = map_more(columns, sum)
    row_sums = map(zip(columns), sum)

Or even, in OO style:
    row_sums = columns:map_more(sum)	-- map_more applies to seq of seqs (**)
    row_sums = columns:zip():map(sum)

(*) Operation is done on tuples composed of n-th argument of every sequence?
(**) May be called zip_map if ever 'zip' become a standard term.

> steve d
> 

Denis
________________________________

la vita e estrany

http://spir.wikidot.com/