 <p>Let's do this.</p> <p>• <strong>I know that lazy sequences only evaluate the items in the sequence that are asked for, how does it do this?</strong></p> <p>Lazy sequences (henceforth LS, because I am a LP, or Lazy Person) are composed of parts. The <strong>head, or the part(s, as really 32 elements are evaluated at a time, as of Clojure 1.1, and I think 1.2) of the sequence that have been evaluated, is followed by something called a <em>thunk</em>, which is basically a chunk of information (think of it as the rest of the your function that creates the sequence, unevaluated) waiting to be called</strong>. When it is called, the thunk evaluates however much is asked of it, and a new thunk is created, with context as necessary (how much has been called already, so it can resume from where it was before). </p> <p>So you <code>(take 10 (whole-numbers))</code> – assume <code>whole-numbers</code> is a lazy sequence of whole numbers. That means you're forcing evaluation of thunks 10 times (though internally this may be a little difference depending on optimizations.</p> <p>• <strong>What makes lazy sequences so efficient that they don't consume much stack?</strong></p> <p>This becomes clearer once you read the previous answer (I hope): unless you call for something in particular, nothing is evaluated. When you call for something, each element of the sequence can be evaluated individually, then discarded. </p> <p>If the sequence is not lazy, oftentimes it is holding onto its head, which consumes heap space. If it is lazy, it is computed, then discarded, as it is not required for subsequent computations. </p> <p>• <strong>How come you can wrap recursive calls in a lazy sequence and no longer get a stack over flow for large computations?</strong></p> <p>See the previous answer and consider: the <code>lazy-seq</code> macro (<a href="http://richhickey.github.com/clojure/clojure.core-api.html#clojure.core/lazy-seq" rel="nofollow noreferrer">from the documentation</a>) will </p> <pre><code>will invoke the body only the first time seq is called, and will cache the result and return it on all subsequent seq calls. </code></pre> <p>Check out the <code>filter</code> function for a cool LS that uses recursion: </p> <pre><code>(defn filter "Returns a lazy sequence of the items in coll for which (pred item) returns true. pred must be free of side-effects." [pred coll] (let [step (fn [p c] (when-let [s (seq c)] (if (p (first s)) (cons (first s) (filter p (rest s))) (recur p (rest s)))))] (lazy-seq (step pred coll)))) </code></pre> <p>• <strong>What resources do lazy sequences consume to do what it does?</strong></p> <p>I'm not quite sure what you're asking here. LSs require memory and CPU cycles. They just don't keep banging the stack, and filling it up with results of the computations required to get the sequence elements. </p> <p>• <strong>In what scenarios are lazy sequences inefficient?</strong></p> <p>When you're using small seqs that are fast to compute and won't be used much, making it an LS is inefficient because it requires another couple chars to create. </p> <p>In all seriousness, <strong>unless you're trying to make something <em>extremely</em> performant, LSs are the way to go.</strong></p> <p>• <strong>In what scenarios are lazy sequences most efficient?</strong></p> <p>When you're dealing with seqs that are huge and you're only using bits and pieces of them, that is when you get the most benefit from using them. </p> <p>Really, it's pretty much always better to use LSs over non-LSs, in terms of convenience, ease of understanding (once you get the hang of them) and reasoning about your code, and speed. </p>