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

[Michael Heerdegen]

Alex <agrambot@gmail.com> writes:

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

Yes, or at least, a cons containing the 0.  That's how things look like
with print-circle enabled.

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

I'm not sure if that is doable without rewriting the implementation,
since the macro expansion is automatically written code.

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

AFAICT `print-circle' and `print-gensym' also control how `prin1'
prints.


Note that when we changed the code to use `cl-gensym', we would not have
a really clean solution for the readability problem: if you print with
p-gensym and p-circle on, it would not look much different than now.  If
you print with those flags off, you (still) print to different (not
equivalent) code: when you read (evaluate) it, all uninterned symbols
would be replaced with interned symbols.  Though, with numbered symbol
names, you will be probably be lucky in most cases that the difference
doesn't matter.

But I see your point: the readability is a real problem.  Maybe we could
instead improve how things are printed?  Unfortunately that lies beyond
my knowledge.


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

I agree but somewhat hesitate because of the variable's name, which is
even more a source of confusion.


Michael.