5

In the following (Clojure) SO question: my own interpose function as an exercise

The accepted answers says this:

Replace your recursive call with a call to recur because as written it will hit a stack overflow

(defn foo [stuff]
  (dostuff ... )
  (foo (rest stuff)))

becomes:

(defn foo [stuff]
  (dostuff ...)
  (recur (rest stuff)))

to avoid blowing the stack.

It may be a silly question but I'm wondering why the recursive call to foo isn't automatically replaced by recur?

Also, I took another SO example and wrote this ( without using cond on purpose, just to try things out):

(defn is-member [elem ilist]
  (if (empty? ilist)
    false
    (if (= elem (first ilist))
      true
      (is-member elem (rest ilist)))))

And I was wondering if I should replace the call to is-member with recur (which also seems to work) or not.

Are there cases where you do recurse and specifically should not use recur?

Community
  • 1
  • 1
SyntaxT3rr0r
  • 27,745
  • 21
  • 87
  • 120
  • btw that *is-member* function I modified to use *if* instead of *cond* (from another SO example) is basically my first "program" in Clojure and probably bogus so be gentle with a Clojure newbie ; ) – SyntaxT3rr0r Sep 29 '11 at 15:38
  • I'm allergic to explicit `true`s and `false`s, so would prefer `(defn is-member? [elem ilist] (and (seq ilist) (or (= elem (first ilist)) (recur elem (rest ilist)))))` – Thumbnail Apr 17 '14 at 09:45
  • ... and, if you want to know when you *can* use tail recursion, look here: http://stackoverflow.com/questions/7813497/clojure-what-exactly-is-tail-position-for-recur – Thumbnail Apr 17 '14 at 09:48

3 Answers3

8

There's pretty much never a reason not to use recur if you have a tail-recursive method, although unless you're in a performance-sensitive area of code it just won't make any difference.

I think the basic argument is that having recur be explicit makes it very clear whether a function is tail-recursive or not; all tail-recursive functions use recur, and all functions that recur are tail-recursive (the compiler will complain if you try to use recur from a non-tail-position.) So it's a bit of an aesthetic decision.

recur also helps distinguish Clojure from languages which will do TCO on all tail calls, like Scheme; Clojure can't do that effectively because its functions are compiled as Java functions and the JVM doesn't support it. By making recur a special case, there's hopefully no inflated expectations.

I don't think there would be any technical reason why the compiler couldn't insert recur for you, if it were designed that way, but maybe someone will correct me.

mqp
  • 70,359
  • 14
  • 95
  • 123
  • 1
    Because if the compiler switched to `recur` for you, you'd have to know/guess when it's doing that anyway. This way, if you try to write a tail-recursive function and fail, the compiler lets you know by refusing to run your code at all. – amalloy Sep 29 '11 at 18:15
7

I asked Rich Hickey that and his reasoning was basically (and I paraphrase)

"make the special cases look special"

he did not see the value in papering over a special case most of the time and leaving people to wonder why if blows the stack later when something changes and the compiler can't guarantee the optimization. Untimely it was just one of the design decisions made to try and keep the language simple

Arthur Ulfeldt
  • 90,827
  • 27
  • 201
  • 284
  • +1 to everyone here... It's very cool to know what Rich Hickey himself said on the topic. Now my problem: I don't know which answer to pick as the "accepted" one ; ) – SyntaxT3rr0r Sep 29 '11 at 20:22
3

I was wondering if I should replace the call to is-member with recur

In general, as mquander says, there is no reason to not use recur whenever you can. With small inputs (a few dozen to a few hundred elements) they are the same, but the version without recur will blow up on large inputs (a few thousand elements).

Explicit recursion (i.e. without 'recur') is good for many things, but iterating through long sequences is not one of them.

Are there cases where you specifically should not use recur?

Only when you can't use it, which is when

  • it is not tail recursive - i.e. it wants to do something with the return value.
  • the recursion is to a different function.

Some examples:

 (defn foo [coll] 
  (when coll 
    (println (first coll))
    (recur (next coll)))   ;; OK: Tail recursive

(defn fie [coll]
  (when coll
    (cons (first coll)       
      (fie (next coll))))) ;; Can't use recur: Not tail recursive.   

(defn fum 
  ([coll] 
    (fum coll []))         ;; Can't use recur: Different function.
  ([coll acc] 
    (if (empty? coll) acc
       (recur (next coll)  ;; OK: Tail recursive
          (conj acc (first coll))))))

As to why recur isn't inserted automatically when appropriate: I don't know, but at least one positive side-effect is to make actual function calls visually distinct from the non-calls (i.e. recur).

Since this can be the difference between "works" and "blows up with StackOverflowError", I think it's a fair design choice to make it explicit - visible in the code - rather than implicit, where you would have to start second-guessing the compiler when it doesn't work as expected.

j-g-faustus
  • 8,801
  • 4
  • 32
  • 42