I fixed the original source code because it had just one parameter (repo) and people kept talking about curry vs partial application since a partial application with one parameter for all the functions is a curried function (from my understand).
Outside of that, understood, I think I have an idea of what should I do with these situations.
Curried function means, that you have a function of a single arg, that returns a function of single arg and so on, until the final value is returned. You curry on the function definition site.
Partial application though, means to not provide all arguments right now and get a function back, which takes the remaining arguments. Partial application is done on the call site.
Currying in Haskell and most ML dialects is it, what makes the partial application easy and effortless.
In Erlang and Elixir there is neither syntactc sugar for currying nor for partial application. So the best thing we can do to partially apply a function is to use the SpecialForms fn/1 and &/1 as already shown before.
Personally, I consider just using &/1 much easier than hand currying a function by hand and then using dotted calls everywhere, despite the fact if I want to partially apply or not.
Because functions are not curried by default, working with curried functions is usually non-idiomatic in Elixir. I did write a library called Currying a while back that lets you curry arbitrary functions. However, partially applying functions in the same way as you’d do in Haskell has two problems in Elixir:
However, partial application based on the two super-helpful special forms that @NobbZ already mentioned as well (fn and &) is super helpful, very idiomatic and widely used in practice.
I do not think there exists a battle between parameters on one hand and partial application on the other: Whenever we use a function, this is where we decide whether we want to fill in all parameters at once, or still keep a couple of them blank (which we can do using fn, &, and/or wrapping the actual function we want to call in a new, descriptively named function). This is a decision for the consumer (the place the function is called) of the code, not the producer (the place the function is defined).