On 12 July 2013 11:36, Haoyi Li email@example.com wrote:
I'd be all for increasing usage of fold and reduce, and higher order combinators in general, but wasn't it always a somewhat philosophical issue that kept lambdas intentionally verbose/crippled and discouraged usage of Higher-Order-Functions when direct imperative code (i.e. loops) works? I've always felt reduce() being banished was but a small facet of this overall philosophy, and not so much because it was individually difficult to use.
data = fold("+=", , iterables)
Seems like a terrible hack to me =( it brings back memories of my PHP days
where "first class functions" meant you passed in the functions name as a
string which got concatted-around and eval-ed. We all laughed at how badly
they designed the language to have it end up like that. Naturally, it is the
path of least resistance, since it could be implemented with existing
language features (i.e.
eval, which can implement anything really) but it
would leave a sour taste in my mouth every time i use it.
I would much prefer the somewhat-more-difficult route of modifying the
parser to let
a += b be an expression, and then you could write
data = fold(lambda a, b: a += b, , iterables)
or even groovy/scala/mathematica style
data = fold(_ += _, , iterables)
Which is a lot further (implementation wise) from where we are now, and 2 characters more verbose, but it would be far more generally usable than a one-off "let's pass in operators as strings and concat/eval them" rule.