Polyvariadic functions can be useful to improve the user experience when writing an EDSL in Haskell.
Instead of making your users write `doSomething ["With", "these", "arguments"]`

, you could have them write `doSomething "With" "these" "arguments"`

.

Your intuition will probably tell you that making a polyvariadic function will be unsafe, but Haskell allows you to make it safe. Of course it is not as easy as in Python, but then again, polyvariadic functions in Python will never be type safe.

### Background: Currying

The concept of currying needs to be very clear before we can dive into polyvariadic functions.

A function with two arguments: `f :: a -> b -> c`

really only has one argument.
The `->`

operator is right-associative, so we can rewrite this type signature as `f :: a -> (b -> c)`

.
This means that `f`

takes a value `x :: a`

and gives you a function `f x :: b -> c`

.

When we write down functions with 'multiple arguments', the parentheses are usually omitted, but in reality `f x y z`

is parsed as `((f x) y) z`

.

### The problem of polyvariadic functions

What we want to build is a function of type `a -> (a -> (a -> (... -> b )))`

where the length of this chain of `->`

operators is determined by how many arguments are given to the function.

Meanwhile, we would like to implement this function as if it were of type `[a] -> b`

.

Keep in mind that, with what I am about to show you, it is also possible to implement more complicated polyvariadic functions (for example with different types as arguments).

### A first draft of a solution

The trick that we will employ to make this happen will involve a typeclass.
Let's say we would like to build the polyvariadic equivalent of a function `sumOf :: [Int] -> Int`

.
We would then write a typeclass `SumArgs`

as follows:

```
class SumArgs a where
sumArgs :: [Int] -> a
```

Instances of this class, 'know how to make a value of their type from a list of integers'.

Next, we instantiate `Int -> r`

where `SumArgs r`

.
(We will need `{-# LANGUAGE FlexibleInstances #-}`

and `{-# LANGUAGE FlexibleContexts #-}`

.)

```
instance (SumArgs r) => SumArgs (Int -> r) where
sumArgs is i = sumArgs (i:is)
```

This may look like black magic at first. I will explain how this works right now. Why it is useful should become clear later.

Note that the `sumArgs`

function in the second instance is of type `SumArgs r => [Int] -> (Int -> r)`

.
That is, given a list of integers `is :: [Int]`

and another integer `i :: Int`

, we have to build a value of type `r`

where `r`

has a `sumArgs`

instance.
`r`

, having a `sumArgs`

instance, can be built using `sumArgs :: SumArgs r => [Int] -> r`

if we have a list of integers. We will build this list by adding `i :: Int`

to the existing list `is :: [Int]`

.

Now we are ready to add the functionality that will use `sumOf :: [Int] -> Int`

in a polyvariadic context.
We will do this with another instance:

```
instance SumArgs Int where
sumArgs = sumOf
```

This instance explains how to build the result (of type `Int`

) from a list of `Int`

arguments.

We could now use sumArgs as `let f = 5 :: Int in sumArgs [] f f :: Int`

and we would already have a polyvariadic function, but the empty list n there is still ugly.

The final piece of the puzzle is to abbreviate this:

```
sumOf' :: SumArgs args => args
sumOf' = sumArgs []
```

There we have it, a type safe polyvariadic function in Haskell.

```
*> let f = 5 :: Int
*> let g = 4 :: Int
*> sumOf' f g :: Int
9
*> sumOf' f g f f g :: Int
23
```

### Under the hood of the black magic

If you did not already get how this works, here is an example.

`sumOf' f g`

is declared to be of type `Int`

, which means we can write it as `sumArgs [] f g :: Int`

.

If we add the parentheses in the right places, we get `((sumArgs []) f) g :: Int`

.
Now we will examine what Haskell's type inference does:

- Peeling off one layer, Haskell figures out that
`(sumArgs []) f`

must be of some type`c -> Int`

where`g`

is of that type`c`

. - Peeling off the next layer, Haskell figures out that
`sumArgs []`

must be of some type`b -> c -> Int`

where`f`

is of that type`b`

. - It knows that
`sumArgs`

is of type`[Int] -> a`

. - It identifies
`a`

with`b -> c -> Int`

to come to the conclusion that`sumArgs`

is of type`[Int] -> b -> c -> Int`

where`b`

and`c`

are the types of`f`

and`g`

, respectively. - Because it knows that
`f`

and`g`

are both of type`Int`

, it specializes the type of`sumArgs`

to`[Int] -> Int -> Int -> Int`

, which is exactly what we want.

The reason that `sumArgs :: [Int] -> Int -> Int -> Int`

is a valid type signature, is because `Int -> Int -> Int`

has an instance of `SumArgs`

.
`Int -> Int -> Int`

has an instance of SumArgs because `Int -> Int`

does.
Finally, `Int -> Int`

has an instance of SumArgs because `Int`

does.

### Backward compatibility

I motivated polyvariadic functions by arguing that they look nice in EDSLs.
If you are interested in improving the user experience of your EDSL, chances are that you have already implemented it.
This means that there is probably already a bunch of code that uses `sumOf :: [Int] -> Int`

directly.
Now, there is a way to change the type of `sumOf`

to `SumArgs args => a`

without breaking any of your users' code and it is by adding one more instance to the above code:

```
instance (SumArgs r) => SumArgs ([Int] -> r) where
sumArgs is n = sumArgs (n ++ is)
```

Now the old code will still work as expected:

```
*> sumOf' [f, g] :: Int
9
```

As a nice bonus, the following now also works:

```
sumOf' f g [f, g] :: Int
18
```