Re: Why are there two dolist?

[Harald Hanche-Olsen <hanche@math.ntnu.no>]

+ Lennart Borgman <lennart.borgman@gmail.com>:

> I do not understand your code above, but is not the conclusion that
> the cl-macs.el version does not do what it is supposed to do?

Yeah, at least as far as the lexically-scoped claim goes.

> What value does it have then?

At least in simpler usage, it does provide a block that return-from
can use for a non-local exit, so it has some value.

Actually, the bug seems to be in block, not in dolist. My example was
perhaps overly complex. Here is a simpler example, using only two
nested blocks, both named b:

(block b
  (flet ((f (x) (return-from b x)))
    (list 'inner-block-returned (block b (f 42)))))

In common lisp, the innermost call (f 42) executes a return-from that
is lexically inside the outer block but not inside the inner one, so
the value 42 is returned from the outer block. In elisp, on the other
hand, the return-from inside foo causes the inner block to return 42,
so the flet, and hence the outer block, returns instead the list
(inner-block-returned 42).

This seems to me to flatly contradict what is said about lexical
scoping in the docstring of block.

Oh, but wait: Looking at the code for block, I begin to suspect that
byte compilation might make a difference. And indeed it does:

(defun foo ()
  (block b
    (flet ((f (x) (return-from b x)))
      (list 'inner-block-returned (block b (f 'bar))))))

(foo) ; => (inner-block-returned bar)
(byte-compile 'foo)
(foo) ; => bar

So byte-compiling a block produces the expected result.

Oh well, I guess this is just one more wart on the cl package. (It has
a few, but I find it useful anyhow.) I still think that inadvertently
using the cl version of dolist cannot possibly harm any elisp code
that does not otherwise rely on cl.

- Harald