GNU bug report logs -
#27177
26.0.50: Macroexpanding cl-loop and friends (make-symbol usage)
Previous Next
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
Message #23 received at 27177 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> With print-circle and print-gensym bound, I think the result does not
> really read worse than how it would look like with with `cl-gensym'
> generated code.
That's much better, though I still think it could/should be better. For
example, if you have multiple uninterned symbols with different
symbol-names, they're all referenced by #number, and use the same
counter.
It also seems to make the output uglier as well. Consider:
(macroexpand '(cl-loop for x in '(1 2 3)
for y in '(a b c)
repeat 10
repeat 20
collect (list x y)))
Note the expressions using #5#. I suppose the 0 is being shared.
It would also be nice if instead of many --cl-var-- variables,
particular clauses would result in different symbol-names. For instance,
if the `repeat' clause made a symbol called --cl-repeat--. This would
further help readability.
Also, using gensym could help 3rd-party packages. I usually use
macrostep to expand macros and the value of print-circle has no effect
on its expansions. macrostep individually prints out each uninterned
symbol using prin1; can this approach be easily modified to get the same
result as macroexpand?
PS: The first line of the documentation of print-circle only mentions
that it affects recursive structures. Perhaps it should mention the
"shared substructures" part in the first line for emphasis?
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.