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(:|)

    array_reduce([1,2,3,4,5], function($v, $e) { return $v | $e; }, 0);

    function or_mask($v, $e) { return $v | $e; }
    array_reduce(array(1,2,3,4,5), "or_mask", 0);

    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 (+)

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]

I suppose that comes at the cost of (+ 1 2 3 4)?

    (def a (+ 1 2 3 4)) ; => $a = (1 + 2 + 3 + 4);

    (fn add (x y)
      (+ x y))

    (map #add [1 2 3])

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.

    {-# 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

    

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.

    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

    +/ 1 2 3 4 5

+/⍳5

  [+] ^6

So correct match would be...

  [+] 1..5

  list(1, 2, 3, 4, 5) reduce(+)

  x: [1 2 3 4 5] forskip x 2 [insert x '+] x: do next x

  x: [1 2 3 4 5] y: [] forall x [repend y [x/1 '+]] take/last y do y

    x ← 1 2 3 4 5
    +/ x

  x.inject(0, &:+)

Still, the Ruby code is pretty readable and a good example of orthogonal concepts that compose well. E.g., getting the product of the numbers instead: x.inject(1, &:*). Or the least common multiple: x.inject(&:lcm).

I'm sorry i couldn't fight the urge to FIFY :( ...