Currying: Elixir library to add currying capability to all your Elixir functions

Awesome! I created a library for currying php functions, inspired by the incredibile mind blowing thing that haskell has been for me. I really love the concept of partial application and curry. Going to check it out for sure!

For the ignorant, what’s the point of currying functions? What’s a use case that it solves for?

Currying plus partial application is just awesome, and after having used some haskell you do miss it really hard everywhere else.

Since I haven’t take a look into @Qqwy’s currying package so far, I will give the examples in haskell.

Given the funtion foldr defined as this:

foldr f z []     = z 
foldr f z (x:xs) = f x (foldr f z xs) 

now your job is to implement map on top of this:

You can use either the very naïv approach to just write it down as this:

map f xs = foldr (\y ys -> f x : ys) [] xs

This is a fully applied function but can be further reduced (eta-reduced to be specific) to the following:

map f = foldr (\x xs -> f x : xs) []

After one gets used to it, it is just cool, but maybe, if you do not know it already, you will probably never miss it

Something in Elixir we could do with currying might look like this (untested):

use Currying

def const(a, _b), do: a

curried_const = curry(&const/2)
Enum.map([1,2,3,4,5,6,7,8,9,10], curried_const.(5))

# without curried:
Enum.map([1,2,3,4,5,6,7,8,9,10], &const(5, &1))

I have to admit, in elixir it looks quite a lot more clear and readable, even more idiomatic to simply use a capture

I think it is nice to play with currying and partial application in elixir, but I might probably stick with pipes and captures, since they are a native language thing, while the curried stuff feels foreign.

Basically: You can only use captures if you exactly know how many arguments you’re going to put in your function right now. In the case of partial application (which might happen in multiple steps), this becomes a problem.

Currying means that you can treat all kinds of functions as unary (taking a single parameter) functions. This allows you to pass them around to higher-order functions (functions that take functions as input). It means that these higher-order functions only have to worry about manipulating unary functions, instead of functions of any arity.

In essence, currying lets you delay the ‘capture’ step to at runtime, instead of having to be defined in your source code.

It is the kind of thing that you will probably not miss when you don’t know about it. On the other hand, there are certain situations that are unsolvable, unless you can curry.

The main reason why I created this library, is that I had such need myself. I am working on another library, called fun_land (it isn’t on Hex yet as it is still unfinished), which creates algebraic data types (basically, ‘containers’ for other kinds of data).

Oh yeah! Now things are getting interesting! Any of the (for haskellers) well-known interfaces that carry over? Monads, Applicatives, other nice stuff?

Yes! I am going the full way, implementing behaviours for semigroups and monoids, reducable and traversable, functors, appliable functors, applicative functors, chainable functors, monads and monad-monoids (known in Haskell as MonadPlus).

Starting with a clean slate means that there are many things that many of the duplicates that were the result of Haskell’s functors being ‘reverse engineered’ like Applicative pure== Monad return, Monad >>==Applicative *>, liftAvs liftM, MonadPlus mzerovs Monoid memptyetc. that can be unified, making it a whole lot more transparent what is going on.

I am am also going to rename some things, to make it as approachable as possible for people new to algebraic data structures. (such as Mappable instead of Functor, Combinable instead of Monoid, wrap instead of return).

Oh, and there are explanations about the different data types involving fruit salad.

The inspiration for the library comes from a JS specification called fantasy land.

If you’d like to check the still-unfinished library out and maybe add some feedback, or point out things that are unclear, you can find FunLand on GitHub .

Don’t you find that the design of the elixir standard library somewhat limits the usefulness of currying?

Typically elixir functions expect the data structure in the first parameter position - and the ubiquitous pipe operator exploits that fact. In Haskell the design pressure of “currying by default” leads to the last parameter position being ideal for the data structure.

That being said partial function application is still tremendously useful.

Don’t you find that the design of the elixir standard library somewhat limits the usefulness of currying?

Yes, you are right. Many functions in Elixir put the ‘most important argument’ at the front for this reason. This is often the parameter that changes the most.

Maybe there is a way to create a currying-like function that leaves the first argument open, although this might be a bad idea as it does not seem very idiomatic to me.

On the other hand, Currying does allow you to do things like:

use Currying

list = [1,2,3,4]

&Enum.into/3
|> curry(list)
|> curry(%{}) 
|> curry(fn x -> {x, x*x} end)

Given that this is just part of your larger effort I think you need to stick with what you have - it’s just that there is going to be an “impedance mismatch” with functions originating from the outside of your library as they are going to apply different criteria for the ordering of their function parameters (including possibly default parameters).

I was talking more about the usefulness of curried functions in isolation, in an environment that doesn’t default to it. In Haskell curried functions seem to be a result of a focus on single parameter functions, i.e. functions that compose easily; curried functions in essence seem to supply a mechanism that allows functions to be “configured” one-parameter-at-time via partial application until they can become part of a function composition (ultimately driving towards the Pointfree style).

So given the process of curried functions being the first step towards function composition I would expect in Elixir “the spirit of currying” to drive toward a pattern like

result = data_struct |> fn1pa |> fn2pa |> fn3pa

which may be useful when the functions in the composition aren’t “configured” (partially applied) inside the current function’s closure.

But within the context of your larger library the goals seem to be entirely different.

Yeah I was thinking of the ‘most changing argument being in first position in Elixir’ too, it is the one big big thing that has bugged me from coming from Erlang, the most changing argument SHOULD be in the last position.

However, the curry could always build things in reverse maybe? Or just special code to put the last argument as the first in the actual call?

EDIT: And on a side note, the most changing argument in last position is a BEAM thing too, the BEAM can optimize function calls that have matching head arguments better than it can matching tails (if the head differs then it has to rebuild the entire argument list instead of being able to re-use the start, yes it is different from how Lists work).