array_sum([1, 2, 3, 4, 5]); array_sum([1, 2, 3, 4, 5]);For example, given a list of numbers, you can generate a bitwise OR mask easily:
[1,2,3,4,5].inject(:|)
What this does is iterate over the list and apply ($last_result | $current_element) and return the result, which is passed on as $last_result to the next iteration. $last_result is 0 by default. This is equivalent to (as of PHP 5.4): array_reduce([1,2,3,4,5], function($v, $e) { return $v | $e; }, 0);
Or prior to PHP 5.3: function or_mask($v, $e) { return $v | $e; }
array_reduce(array(1,2,3,4,5), "or_mask", 0);
It's doable in both languages, but Ruby's functional language lineage and its object-oriented nature results in an exceptionally clean approach. array_reduce(array(1,2,3,4,5), create_function('$v, $e', 'return $v | $e;'), 0);The problem with array_sum is not that it's too long but instead that it's combined two rather specific bits of functionality into a fixed (if common) form, while the Ruby code separates the ideas of "folding" and "addition" allowing for many orthogonal creations.
To pick another favorite, in Haskell you could write
Foldable.foldl1 (+)
which sums any foldable thing—anything which has elements which can be combined together one-by-one. So it'll apply to Trees or Sets or Dictionaries (well, Maps) just as easily while also allowing things like (+) to be replaced by other binary operators.Edit: Screw it, haven't self promoted on a while. In Pharen (https://github.com/scriptor/pharen), which compiles to PHP, you could do:
(reduce (+) 0 [1 2 3 4 5]) ((+ 1) 2) ; => 3
(map (* 2) [1 2 3]) ; => [2 4 6]
If a function f takes any arguments and Pharen knows this, it'll convert (f) into a partial function call as well. Unfortunately I haven't figured out a way to check if a function has any side effects. Otherwise in this case at least operators are treated like functions.I suppose that comes at the cost of (+ 1 2 3 4)?
There are many ways to mitigate that ambiguity statically and dynamically, but I feel there's always going to be a tradeoff between favoring partial application, favoring variadic functions, and the complexity/sophistication of your static checking or runtime environment.
I just made a stab at where the solution might lie in that design space. Turns out I was wrong.
{-# OPTIONS -fglasgow-exts #-}
class BuildList a r | r-> a where
build' :: [a] -> a -> r
instance BuildList a [a] where
build' l x = reverse$ x:l
instance BuildList a r => BuildList a (a->r) where
build' l x y = build'(x:l) y
varargs x = build' [] x
main = print $ ( sum $ varargs 1 2 3 4 5 6 100)
$ ./Test
121
http://okmij.org/ftp/Haskell/vararg-fn.lhs (def a (+ 1 2 3 4)) ; => $a = (1 + 2 + 3 + 4);
Of course, there are situations where partial application won't always happen because the compiler is unable to detect it: (fn add (x y)
(+ x y))
(map #add [1 2 3])
Pharen won't be able to realize that `add` here is being partially applied inside `map`. It's not smart enough for that yet. If you try to run this you'll end up with 'Missing argument 2' and 'Undefined variable: y' all over the place.However, I'm not putting a whole lot of emphasis on partials. They're there as a convenience, but they're not really a core part of the language.
But yes, back to the original point, all the tracking is done at compile time so that for addition with two or more arguments the resulting PHP will look like regular addition in PHP.
foreach(array(1,2,3,4,5) as $x) $i=$i+$x; echo $i;2. ?
3. Profit.
Step 2 is actually extremely well known.
(Added in PHP 6)
Edit: Strike 'maybe'. I looked at it again and it's definitely horrifying. I saved it anyway, though; Halloween's only a few weeks off, and I think I shall print it out and stick it on the wall of my cube next to the PHP hammer and the "periodic" table of Perl 6 operators.
irb(main):001:0> x = [1,2,3,4,5]
=> [1, 2, 3, 4, 5]
irb(main):002:0> x.inject &:*
=> 120