Returning Functions from Functions in Clojure

If passing a function as an argument lets you choose behavior at the call site, returning a function lets you configure behavior once and reuse it later.

That is the core idea behind this section.

In Java terms, this often replaces small factory classes, strategy objects, or configuration-heavy builders. In Clojure, it is often just a function that returns a function.

Closure: A function value that retains access to bindings from the scope where it was created.

The Core Shape

Here is the smallest useful example:

1(defn multiplier [factor]
2  (fn [x]
3    (* factor x)))
4
5(def double-it (multiplier 2))
6(def triple-it (multiplier 3))
7
8(double-it 10)
9;; => 20

The returned function “remembers” factor because it closes over that binding.

That is the important concept:

• the outer function chooses configuration
• the inner function does the later work
• the closure keeps the needed values available without a mutable object

Why This Matters To A Java Developer

The closest Java comparison is returning a lambda that captures local variables.

That comparison is useful, but Clojure makes the pattern much more central to ordinary design.

This does not mean records, protocols, and Java classes disappear. It means you should not reach for a heavier abstraction when a closure already models the problem cleanly.

Two Common Ways To Return Functions

1. Write The Inner Function Explicitly

This is best when the returned behavior has real logic:

1(defn order-validator [minimum-total]
2  (fn [order]
3    (and (= :draft (:order/status order))
4         (>= (:order/total order) minimum-total))))

Now you can build specialized validators:

1(def premium-order? (order-validator 1000M))
2(def standard-order? (order-validator 100M))

2. Use partial When The Shape Is Simple

Sometimes you are only fixing one or more arguments of an existing function.

1(def premium-discount
2  (partial * 0.90M))
3
4(premium-discount 200M)
5;; => 180.00M

partial is ideal when the returned function is just “this function, with some arguments already supplied.”

But it is not always the clearest choice. If the callback needs explanation or domain meaning, a named fn or defn is often easier to read.

A Design Rule That Helps

Use a returned function when:

• some configuration is chosen now
• the actual data arrives later
• the behavior will be reused more than once

That shape appears constantly in real programs:

If the code has that shape, returning a function is usually a good fit.

Closures Are About Values, Not Magic State

Closures often feel mysterious until you remember what is really happening:

the returned function simply retains access to bindings from the outer call.

1(defn make-greeter [prefix]
2  (fn [name]
3    (str prefix ", " name)))
4
5(def greet-customer (make-greeter "Welcome"))
6(greet-customer "Ava")
7;; => "Welcome, Ava"

No global variable is involved. No object field had to be introduced. The function keeps access to prefix because it was created in that scope.

A Useful REPL Nuance About partial

One subtle point matters during interactive development:

partial captures the function value it receives, not future redefinitions of the var at the REPL.

That means code like this can surprise you while experimenting:

1(defn score [x] (* 2 x))
2(def score-twice (partial score))

If you later redefine score at the REPL, score-twice still holds the old function value. The official Clojure FAQ calls this out directly.

In normal running applications, this is usually irrelevant. In active REPL work, it means:

• partial is still correct
• but if you expect live redefinition behavior, an explicit wrapper can be clearer

When Returning A Function Is Better Than Returning Data

Do not force this pattern everywhere.

Return a function when the result is genuinely reusable behavior.

Return data when the result is just configuration.

If callers still need to interpret the result before doing anything useful, returning data may be the clearer design.

Knowledge Check