[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27177: 26.0.50: Macroexpanding cl-loop and friends (make-symbol usag
From: |
Alex |
Subject: |
bug#27177: 26.0.50: Macroexpanding cl-loop and friends (make-symbol usage) |
Date: |
Wed, 31 May 2017 18:29:41 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
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.