95

I have twice recently refactored code in order to change the order of parameters because there was too much code where hacks like flip or \x -> foo bar x 42 were happening.

When designing a function signature what principles will help me to make the best use of currying?

Stephen Kennedy
  • 20,585
  • 22
  • 95
  • 108
John F. Miller
  • 26,961
  • 10
  • 71
  • 121

3 Answers3

114

For languages that support currying and partial-application easily, there is one compelling series of arguments, originally from Chris Okasaki:

  • Put the data structure as the last argument

Why? You can then compose operations on the data nicely. E.g. insert 1 $ insert 2 $ insert 3 $ s. This also helps for functions on state.

Standard libraries such as "containers" follow this convention.

Alternate arguments are sometimes given to put the data structure first, so it can be closed over, yielding functions on a static structure (e.g. lookup) that are a bit more concise. However, the broad consensus seems to be that this is less of a win, especially since it pushes you towards heavily parenthesized code.

  • Put the most varying argument last

For recursive functions, it is common to put the argument that varies the most (e.g. an accumulator) as the last argument, while the argument that varies the least (e.g. a function argument) at the start. This composes well with the data structure last style.

A summary of the Okasaki view is given in his Edison library (again, another data structure library):

  • Partial application: arguments more likely to be static usually appear before other arguments in order to facilitate partial application.
  • Collection appears last: in all cases where an operation queries a single collection or modifies an existing collection, the collection argument will appear last. This is something of a de facto standard for Haskell datastructure libraries and lends a degree of consistency to the API.
  • Most usual order: where an operation represents a well-known mathematical function on more than one datastructure, the arguments are chosen to match the most usual argument order for the function.
Don Stewart
  • 137,316
  • 36
  • 365
  • 468
  • As a corollary to the first bullet point, also put the argument that may live in a data structure last. It makes map, fold and friends cleaner. tl;dr thing in list go last. – John F. Miller May 11 '11 at 03:11
  • 1
    Lookup can't be chained anyways, so the first point doesn't support that aside. http://www.haskell.org/haskellwiki/Parameter_order makes a cogent argument the other way around - "Since objects of type Map represent mappings, it is natural to have some function which transforms a Map object to the represented function." – Brandon Jan 11 '13 at 19:38
11

Place the arguments that you are most likely to reuse first. Function arguments are a great example of this. You are much more likely to want to map f over two different lists, than you are to want to map many different functions over the same list.

hammar
  • 138,522
  • 17
  • 304
  • 385
  • 5
    If you are in fact mapping many functions over the same list, perhaps you should make a list of functions, and `map ($myList)` over that list instead. – Squidly May 03 '11 at 07:27
3

I tend to do what you did, pick some order that seems good and then refactor if it turns out that another order is better. The order depends a lot on how you are going to use the function (naturally).

augustss
  • 22,884
  • 5
  • 56
  • 93