Jeremy Howard writes:
: How much hand-waving can we do with implementation efficiency of anonymous
: subs and higher order functions? How much can we expect Perl to optimise
: away at compile time? For instance, if:
:
: $sum = reduce ^_+^_, @list;
:
: has any substantial overhead on each iteration it would be useless for any
: decent sized number crunching. Other areas where this is a huge issue are
: lazily generated lists (RFCs 81, 90, and 91), and implicit array loops (RFC
: 82). I've been kind of assuming that functions act on whole lists without
: mutating them (RFC 82 operators, map, grep, reduce, ...) would be called in
: a 'special way' that avoided the overhead of "real" sub calls. As I've
: mentioned before, I've also put in various RFCs that this kind of stuff
: should be evaluated lazily...
:
: So anyway, if any of this is just so out of the question that we shouldn't
: even consider the possibility, now is a great time to let us know!
I think, even if we relegate currying to some kind of high-powered
macro system, as long as the operator in question has a good enough
prototype, we can be pretty efficient in how we rewrite things. For
instance, it seems to me that if we somehow know that the first
argument to a reduce should be a sub that wants two arguments, we could
count the placeholders and rewrite the curried expression accordingly
without the nested ?: of the naive rewrite.
Larry
