Lazy Evaluation

Lazy evaluation means some computation is deferred until the result is actually needed. In Clojure, this matters most around sequences. Many sequence operations do not realize all results immediately; they produce values as you consume them.

For Java developers, the closest familiar comparison is often stream-style deferred processing, but Clojure’s lazy sequence model has its own habits and pitfalls.

The simplest useful idea

If an operation is lazy, building the sequence is not the same thing as fully doing the work.

1(def numbers (map inc [1 2 3]))
2
3numbers
4;; => (2 3 4)

The key point is not the printed result. The key point is that map returns a lazy sequence rather than eagerly constructing a final realized collection.

Why laziness helps

Laziness is useful because it can:

• avoid work you never consume
• let you process large logical sequences incrementally
• support pipelines that stay composable
• make infinite sequences possible

For example:

1(take 5 (range))
2;; => (0 1 2 3 4)

An infinite range is only practical because you consume a finite prefix.

Why laziness is not “free”

Laziness improves flexibility, but it also changes when work happens.

That means you should ask:

• when is this sequence actually realized?
• where do side effects occur?
• am I holding onto more of the sequence than I intended?

If you ignore those questions, lazy code can become surprising.

Side effects and laziness do not mix cleanly

This is a classic beginner trap:

1(map println [1 2 3])

That returns a lazy sequence. If nothing consumes it, the printing may not happen the way you expect.

If your goal is effects, use a construct that exists for effects, or force realization deliberately.

For Java developers, this is similar to forgetting that a stream pipeline does not execute until a terminal operation happens, but the lesson is even more important in Clojure because laziness shows up pervasively in sequence code.

Chunking can surprise you

Some lazy sequence operations realize elements in chunks rather than one-by-one. That means asking for one element may cause more than one element’s worth of work to happen behind the scenes.

This matters when:

• debugging evaluation behavior
• mixing laziness with effects
• expecting exact one-at-a-time realization

So “lazy” does not always mean “one item at a time with no lookahead.”

Retaining the head can retain more memory

Another common pitfall is keeping a reference to the head of a lazy sequence while processing deep into it. That can keep earlier parts reachable longer than you intended.

When memory behavior matters, ask whether you really want:

• a lazy seq
• a realized collection
• a transducer-based process
• or a loop/recur style pipeline

Laziness is useful, but it is not always the right memory shape.

Java comparison that helps

Java Streams teach similar instincts:

• building the pipeline is not the same as executing it
• side effects inside the pipeline should be treated carefully
• terminal consumption matters

Clojure sequences add their own flavor because sequence functions are deeply woven into ordinary code, not isolated in one streaming API.

A practical rule

Use laziness when you want deferred, incremental, or potentially unbounded sequence processing. Be cautious when you need:

• precise evaluation timing
• predictable one-at-a-time effects
• tight memory control

In those cases, a different tool may fit better.

Knowledge Check