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

Previous Next

Package: emacs;

Reported by: Alex <agrambot <at> gmail.com>

Date: Wed, 31 May 2017 23:25:02 UTC

Severity: minor

Found in version 26.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Alex <agrambot <at> gmail.com>
Cc: 27177 <at> debbugs.gnu.org
Subject: bug#27177: 26.0.50: Macroexpanding cl-loop and friends (make-symbol usage)
Date: Thu, 01 Jun 2017 01:51:42 +0200
Alex <agrambot <at> gmail.com> writes:

> Consider the following simple cl-loop form:
>
> (cl-loop for x in '(1 2 3)
>          for y in '(a b c)
>          collect (list x y))
>
>
> The macroexpanded result is:
>
> (cl-block nil
>   (let*
>       ((--cl-var--
>         '(1 2 3))
>        (x nil)
>        (--cl-var--
>         '(a b c))
>        (y nil)
>        (--cl-var-- nil))
>     (while
>         (and
>          (consp --cl-var--)
>          (progn
>            (setq x
>                  (car --cl-var--))
>            (consp --cl-var--)))
>       (setq y
>             (car --cl-var--))
>       (push
>        (list x y)
>        --cl-var--)
>       (setq --cl-var--
>             (cdr --cl-var--))
>       (setq --cl-var--
>             (cdr --cl-var--)))
>     (nreverse --cl-var--)))
>
>
> It's easy to verify that this expansion doesn't do the same job by
> noticing that the macroexpanded form always returns nil.
>
> Note that in Common Lisp (at least in SBCL), macroexpanding and then
> evaluating the result works as expected.

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))

> This is because cl-macs.el uses make-symbol instead of gensym, like SBCL
> does.

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.

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


Michael.




This bug report was last modified 4 years and 351 days ago.

Previous Next


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