Currying and Partial Application in Clojure

Currying and partial application are related ideas, but they are not the same thing. In Clojure, the distinction matters because the language does not automatically curry ordinary functions. That means partial application is the more common everyday tool, while currying is usually something you model deliberately when it helps.

The Difference

Currying means transforming a multi-argument function into a chain of one-argument functions.

Partial application means taking a function and fixing some of its arguments ahead of time to produce a new function with fewer inputs left to supply.

In practice:

• currying changes the function shape
• partial application pre-fills arguments

Partial Application Is The Daily Tool

Most Clojure code reaches for partial or a closure rather than for explicit currying.

1(defn charge [gateway currency amount]
2  {:gateway gateway
3   :currency currency
4   :amount amount})
5
6(def charge-usd
7  (partial charge :stripe :usd))
8
9(charge-usd 5000)

This is simple and useful. A general function becomes a specialized one without introducing ceremony.

Closures often read just as well or better:

1(defn make-charger [gateway currency]
2  (fn [amount]
3    (charge gateway currency amount)))

That style is especially helpful when the specialized function needs a meaningful constructor name.

When Currying Helps

Currying is more niche in Clojure, but it can still clarify some designs:

• building layered configuration
• modeling staged function construction
• exposing point-free or pipeline-friendly APIs in small libraries

1(defn curried-discount [rate]
2  (fn [subtotal]
3    (* subtotal (- 1 rate))))

This is explicitly curried because each stage returns the next function in the sequence.

Why Clojure Usually Prefers Simpler Shapes

Clojure code often prefers:

• plain functions with explicit parameters
• closures for specialization
• partial when argument fixing is obvious

That is because readability matters more than proving a concept from functional programming theory. If currying makes the call shape harder to understand, it is the wrong tool.

Good Uses

Partial application and currying are useful when:

• you want to preconfigure behavior
• several callers share the same leading arguments
• a pipeline becomes clearer when specialized functions are named
• dependency injection can be expressed as returning configured functions

They are especially common in:

• validation helpers
• predicates
• middleware constructors
• query builders
• function factories

Common Mistakes

The first mistake is pretending Clojure is automatically curried. It is not. If you want curried behavior, you must model it intentionally.

The second mistake is overusing partial until the remaining call shape becomes mysterious. A named wrapper function is often clearer.

The third mistake is fixing arguments just because you can, not because it improves the API.

Design Review Questions

Ask these when reviewing currying or partial application:

• Does the specialized function become easier to name and reuse?
• Is the remaining argument list still obvious to the caller?
• Would a closure read better than partial here?
• Is currying helping composition, or just adding cleverness?

Good use of these tools makes code smaller and more explicit. Bad use makes the reader reconstruct hidden argument order.