bug#27177: 26.0.50: Macroexpanding cl-loop and friends (make-symbol usage)

[Alex]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Also in Elisp:
>
> (eval (macroexpand '(cl-loop for x in '(1 2 3)
>                         for y in '(a b c)
>                         collect (list x y))))
> ==>
> ((1 a)
>  (2 b)
>  (3 c))

Right, sorry for not being clear. I was referring to printing the output
into a buffer and evaluating that instead of feeding it directly into
eval.

Though I was wrong that SBCL does this correctly by default (you have to
set *print-gensym* to nil).

> Note that `make-symbol' doesn't return an interned symbol - what is
> printed as "--cl-var--" above are actually different symbols.  You need
> to enable `print-gensym' to make that visible when printing the
> macroexpansion.  If you print with print-gensym bound to nil, you don't
> get a correct printed representation.

Enabling print-gensym in this case is even worse, since evaluating the
macroexpanded code yields a (void-variable #:--cl-var--) error.

> So I think there is not a bug, unless your complaint is about human
> readability or the default value of `print-gensym'.

Human readability is indeed a large part of my complaint.

Also, evaluating the macroexpanded code directly would allow for easier
debugging, since one could make small adjustments to the output to see
immediate results.