I'm currently learning Clojure (my first functional programming language), and I'm curious as to its order of evaluation.

Here is an example:

(take 10 (cycle [1 2 3]))

If the cycle expression was not wrapped in a take expression, this would cause a memory error, as it would iterate infinitely through the vector. So, how does Clojure know that it has been wrapped with a take expression?

(If I'm using any incorrect terminology here, I'd appreciate a nudge too!)

  • For observing evaluation of lazy seqs, something like (def my-observable-seq (map (fn [x] (println x) x) my-lazy-seq)) is great. Disclaimer: I probably wouldn't use it in real code.
    – user39685
    Commented Apr 14, 2014 at 11:55

2 Answers 2


So, how does Clojure know that it has been wrapped with a take expression?

It doesn't. Lazyness is better understood like this: nothing is ever evaluated unless it's absolutely necessary. The cycle function has the semantics of "repeat things endlessly", but this doesn't actually happen until the interpreter has to prove to you, the user, that it does. If the sequence only had to produce a value, even an infinite one, it would do nothing at all, and there would be no way for you to notice. What does start the actual computation is the need to deliver something to the caller, in this case take 10. It has to know what elements to operate on, so the cycle function reluctantly produces 10 values, but no more.

The take function, in turn, only produces a value. If it were alone in the world, it might just as well not bother to do anything at all, but it's called by the REPL, which must print values onto the terminal per its contract. Ultimately, the need to print the first character of the result is what drives the entire computation. This is exactly the opposite of the traditional approach where an inner expression is evaluated to completion and then passed on to the next level.

  • Thanks Kilian, it's just starting to click in my head, now that I can research the concept of lazyness. Is WuHoUnited's answer the technical equivalent of your summary?
    – joecritch
    Commented Apr 13, 2014 at 18:28
  • Yes, streams and interfaces that allow callers to control how much to compute via next are one common way of implementing lazyness. Commented Apr 13, 2014 at 19:47
  • 3
    The problem with this answer is that in general, Clojure does not do lazy evaluation (unlike say, Haskell, where everything is lazy). The apparent lazy evaluation in the example above is a result of the lazy generation semantics of the Clojure seq interface. Commented Apr 14, 2014 at 1:32
  • You're completely right. I just thought that for a user new to the concept it would be more useful to explain lazyness itself first, and not add complications about how Clojure is actually a mixed-paradigm platform. Commented Apr 14, 2014 at 6:02

Your issue here seems to be specifically around Clojure's sequences which can be infinite.

Clojure's sequences can either be null or implement an interface called ISeq, which among other things has 2 particularly important functions, first and next.

Consider the following java class

public class LongsFrom implements ISeq{
    private Long _currentNumber;

    public LongsFrom(Long start){
        _currentNumber = start

    public Object first(){
        return _currentNumber;

    public ISeq next(){
        return new LongsFrom(_currentNumber + 1);

It represents an infinite sequence of increasing numbers starting wherever you want. As you keep calling next() on it, you keep realizing more and more of the sequence, however all you really need to keep in memory is whatever the latest object in the sequence is.

What cycle does is create an instance of a class which implements the ISeq interface (it knows how to calculate the sequence but doesn't actually do it until you start calling next). Then your take command actually starts calling first and rest on this class to get however much of the sequence it needs.

A class which actually performs cycle would only be slightly more complicated than my LongsFrom example. The cycle class could have 2 private variables, one which holds the list of things it needs to cycle through and then an integer to remember which index it's currently on. first would return the item at the current index. next would return a new cycle object with the exact same internal list, but an index of 1 + currentIndex (unless we're at the end of the list in which case we start the index back at 0)

The reason why you have memory issues if you don't have the take command is that if you don't have the take command, the repl tries to print the sequence and the default implementation for print is to keep calling first and rest until the sequence ends (which is never in the case of cycle)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.