Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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!)

share|improve this question
    
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 Apr 14 at 11:55

2 Answers 2

up vote 6 down vote accepted

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.

share|improve this answer
    
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 Apr 13 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. –  Kilian Foth Apr 13 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. –  Greg Hewgill Apr 14 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. –  Kilian Foth Apr 14 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)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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