If we take maths as our source of truth(since most constructs of this kind come from there), then I’d argue the arity should be 1, based on notions from lambda calculus.

If we consider the expression *λx.λy.x*, giving it an *x* will result in an abstraction that, no matter what *y* we feed it, it will always return *x*. The resulting abstraction would be *λx.y* which is the **constant function x↦y**. The abstraction that produces such constant functions is the constant combinator **K** = λx.λy.x.

The identity combinator **I** is already incarnated in `Function.identity`

, if the **K** combinator is implemented, we would only need to add the **S** combinator *λfgx.fx(gx)*:

```
def substitution(f) do
fn g ->
fn x ->
(f.(x)).(g.(x))
end
end
end
```

And this would complete the three combinators needed for SKI combinator calculus.

The other argument for **K**’s returned function to have an arity of 1, is that a lot of this work involves giving one argument at a time to partially apply those functions, and it just makes no sense to have more arguments. Having zero arguments also goes against the definition of *x↦y*.

Another observation is that such constant function is the *return* value, what’s being proposed is the combinator that produces it. `Function.constantly(code)`

and `fn -> code end`

will behave differently because the former is an invocation to the combinator, and the latter is the produced function. Moreover, if you give a function to `Function.constantly/1`

, then expect the constant function to return the same function, not to evaluate it.

I don’t know what was the motivation behind the addition of `Function.identity/1`

, but I’m not sure if it’s worth it to implement these combinators in elixir itself, or it’s best to leave it for userland code. I think that once you add one you’ll be tempted to add the others, and I don’t know if that’s the goal of the `Function`

module.

I also understand that Elixir is a pragmatic language and academic purity is not it’s goal, but if we are going to implement these abstractions then we need to pick something that’s already been generalized and well understood, otherwise we would end up discussing which arity the function should have considering x, y and z practical examples, and for such cases I believe ad-hoc functions are the best.