In defense of LOOP

Joe Marshall gives some reasons to hate LOOP and I can't say I disagree with him, save for has last point.

LOOP encourages users to think linearly, sequentially, and iteratively. They start trying to flatten everything into a single pass, first-to-last, state-bashing mess. Suddenly they forget about recursion. I've seen this happen over and over again. It literally damages the thought process.

This alludes to the old iteration versus recursion quagmire which is analogous to static versus dynamic "debates." Joe's self-professed knee-jerk reaction isn't going to get me to stop me from using LOOP, nor will it convince me to use recursion more. With both, I will use the one that fits the problem best given the context in which it is written.

Mapping over hash tables is one such example. Suppose I have a hash table whose values are lists and I want to calculate the sum of the length of all the lists. LOOP provides a succinct and clear way to express it.

(loop for list being each hash-value in htable
      sum (length list))

The MAPHASH and WITH-HASH-TABLE-ITERATOR approaches aren't quite as simple (although, admittedly, not difficult for this problem).

LOOP is also really handy for short-circuiting.

(defun first-n-things (list pred n)
  (loop with count = 0
        for e in list
        when (funcall pred e) collect e and do (incf count)
        until (= count n)))

I can't say I'm fond of the LABELS approach to the latter.

(defun first-n-things-2 (list pred n)
  (labels ((helper (elems count acc)
             (cond ((or (null elems) (= n count))
                    acc)
                   ((funcall pred (first elems))
                    (helper (rest elems) (1+ count) (cons (first elems) acc)))
                   (t (helper (rest elems) count acc)))))
    (helper list 0 nil)))

Using an &OPTIONAL parameter as an accumulator is only slightly cleaner.

(defun first-n-things-3 (list pred n &optional acc)
  (cond
    ((or (null list) (zerop n))
     acc)
    ((funcall pred (first list))
     (first-n-things-3 (rest list) pred (1- n) (cons (first list) acc)))
    (t (first-n-things-3 (rest list) pred n acc))))

Debunking the "LOOP damages the thought process" claim isn't the point here, since I don't think it was meant to be an assertion in the first place. LOOP makes dealing with state a lot cleaner when it comes up, but I agree that there is no need to use it when a simple MAPCAR will do. Sometimes recursion is messy, sometimes it isn't. Frankly, I go back forth between the two all the time, trying to find the best way to express my problem, just like I do when I'm writing. I don't always succeed, but I want to keep my options open.