<div dir="ltr">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.<div>
<br></div><div>> <span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">data = fold("+=", [], iterables)</span></div><div><br></div><div>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.</div>
<div><br></div><div>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</div><div><br></div><div>data = fold(lambda a, b: a += b, [], iterables)</div>
<div><br></div><div>or even groovy/scala/mathematica style</div><div><br></div><div><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">data = fold(_ += _, [], iterables)</span><br></div><div><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">-Haoyi</span></div><div><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px"><br>
</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 6:11 PM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im">On 12 July 2013 09:03, Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com" target="_blank">abarnert@yahoo.com</a>></span> wrote:<br>
</div><div class="im"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Meanwhile, there are an awful lot of people who just don't like reduce/fold in any situation. The quote "Inside every reduce is a loop trying to get out" appears quite frequently, on this list and elsewhere.</blockquote>
</div><br></div>And yet we keep getting cases like the sum discussion which is a fold in essence, but people reject suggestions of "just use a loop". So it doesn't look like the loop is trying very hard to get out :-)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Whether "inside every specialised function there is a fold trying to get out" is any more likely to gain traction, I don't know...</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">
<br></div><div class="gmail_extra">Paul</div></font></span></div>
<br>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
<br></blockquote></div><br></div>