[tel]

So it's tracking the arity of functions and turning anything which has been applied to fewer than ARITY arguments to a partial application?

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

[Scriptor]

It does track the arity of functions, but remember that this happens at compile time. Regular addition in Pharen is still just regular addition in PHP:

    (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.

[tel]

Gotcha, very interesting!

[knome]

Surprisingly, not really.

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

[tel]

I love that example, but it does depend upon some pretty arcane features in Haskell's type inference engine.

[aaronem]

Why would it?

[tel]

My hypothesis was that the compiler was tracking the arities of each function in order to open up opportunities for partial application. That means there's some ambiguity when you write something like (+ 1) which, in Scheme is a complete application equal to 1 but may also be interpreted as a partial application equal to (lambda (x) (+ 1 x)).

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.