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

Previous Next

Full log

Message #14 received at 27177 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 27177 <at> debbugs.gnu.org
Subject: Re: bug#27177: 26.0.50: Macroexpanding cl-loop and friends
 (make-symbol usage)
Date: Wed, 31 May 2017 18:29:41 -0600

Michael Heerdegen <michael_heerdegen <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.