[Python-ideas] Rehabilating reduce (as "fold")

[Joshua Landau]

On 12 July 2013 11:36, Haoyi Li <haoyi.sg at gmail.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.

https://github.com/lihaoyi/macropy#quick-lambdas