<div dir="ltr">> <a href="https://github.com/lihaoyi/macropy#quick-lambdas" target="_blank" style="font-family:arial,sans-serif;font-size:13px">https://github.com/lihaoyi/macropy#quick-lambdas</a><div><br></div><div>Yeah I'm the author of that =D</div>

<div><br></div><div>My point wasn't so much that "use my cool macroz!!!" as "passing operator as string PHP-style makes me sad =(" and with examples of how other languages do it that doesn't make me sad.</div>

<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 7:58 PM, Joshua Landau <span dir="ltr"><<a href="mailto:joshua@landau.ws" target="_blank">joshua@landau.ws</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 12 July 2013 11:36, Haoyi Li <<a href="mailto:haoyi.sg@gmail.com">haoyi.sg@gmail.com</a>> wrote:<br>


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