From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#27177: 26.0.50: Macroexpanding cl-loop and friends (make-symbol usage) Date: Fri, 02 Jun 2017 05:27:16 +0200 Message-ID: <87inkfrrvv.fsf@drachen> References: <8737bk8vba.fsf@gmail.com> <87tw40y48h.fsf@drachen> <87shjk7doq.fsf@gmail.com> <87poeoy0zk.fsf@drachen> <87lgpc79e1.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1496374092 5034 195.159.176.226 (2 Jun 2017 03:28:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Jun 2017 03:28:12 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: 27177@debbugs.gnu.org, npostavs@users.sourceforge.net To: Alex Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 02 05:28:08 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGdFv-00010C-T8 for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Jun 2017 05:28:08 +0200 Original-Received: from localhost ([::1]:47692 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGdG1-0004iQ-8O for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Jun 2017 23:28:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGdFu-0004iL-42 for bug-gnu-emacs@gnu.org; Thu, 01 Jun 2017 23:28:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGdFq-0001iQ-Tq for bug-gnu-emacs@gnu.org; Thu, 01 Jun 2017 23:28:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47580) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dGdFq-0001hf-QH for bug-gnu-emacs@gnu.org; Thu, 01 Jun 2017 23:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dGdFq-0003ii-Gm for bug-gnu-emacs@gnu.org; Thu, 01 Jun 2017 23:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Jun 2017 03:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27177 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27177-submit@debbugs.gnu.org id=B27177.149637406314276 (code B ref 27177); Fri, 02 Jun 2017 03:28:02 +0000 Original-Received: (at 27177) by debbugs.gnu.org; 2 Jun 2017 03:27:43 +0000 Original-Received: from localhost ([127.0.0.1]:50257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGdFV-0003iA-CG for submit@debbugs.gnu.org; Thu, 01 Jun 2017 23:27:43 -0400 Original-Received: from mout.web.de ([212.227.15.14]:63230) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGdFS-0003hu-0h for 27177@debbugs.gnu.org; Thu, 01 Jun 2017 23:27:38 -0400 Original-Received: from drachen.dragon ([94.218.223.218]) by smtp.web.de (mrweb004 [213.165.67.108]) with ESMTPSA (Nemesis) id 0M69CU-1e5Xrz2nfu-00y93Q; Fri, 02 Jun 2017 05:27:17 +0200 In-Reply-To: <87lgpc79e1.fsf@gmail.com> (Alex's message of "Wed, 31 May 2017 20:02:30 -0600") X-Provags-ID: V03:K0:ghrrUF5/y0GwqonmxQQxYhLgDH0ddqfJftxLl8/z9X0mdWUPV74 JhzEqOEXhoACu/zuyqnH3pGJQwuSwx8Hcw+lIIDZO9wDCEzAUFcyhhz8SJq2WkoouEyWnH4 JyaWuOKmkmDplSMioMwZaOQSsyCwx1Q2pmj/wVULn6NGrylIWxpGWIePyRf4c+0zvaZ33QV yLRzzu4k2EGckXmcotQhw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Pj6UNRxTwVM=:4/EH6ECiFs/zUyQW4ghrKL V9QRh3TZDsyB4t12sQ6cKvXeVIj6Kc9NmF8S35DcTqrnVi4DdRCCRpSpAJqoFoblhQPic4ZSa QdJW5Jx0QunVFanmcs9UB+hRkW2tzsaGllu55gKGUylPZGiQBLn4iDGHDzredGwiuVX3oNAQv NpZKWNW4jOMsecJMT8dkGp6n5WNB4QegYIMEF4b6Dla0TtEzeE5551p0noxURK3OtE4JWLxfP E6QQxsdV5MN3ldcx/BZuWVN+4b2iVZ6q2C9al515eQgbS/Q9bMcNJWvslcBI7AccWCAsdpqJE uL7XipSVAa8OPlbuMLdbHDkTSsoqoEfwm4suAHW8hmnLLN3ybNVSlccODl44eO+swbEQ1hjTq TdE37jsSjSbZrj9wP36xld1+HETgeMfprub2i9eAYuxZmCGUB4qwSQGkzPE6glJOd0JZvnzZE 636dc3n7zIIcHUbrS18Be1zCuM4bDCzfEDLpi55ko4MnKe8f+ZNjGV92Zx4evC+Gks1+nFBW1 TZE2DGcwKYW32a1NxHc8IfkumQHD67fO3HZv5csYEQTERZ9TaIllyxMU9emtAfUTHNIMiMOPY T5q620FiRozR4BM6TitD0tqENGh4HxWkwy6jMGJrjoiEI0GUfTnWtURX77pLvy/L4YV8rlcME OnbyK2lCzwI3wJB0xs6N4Z8601U7fd+7a/9tsnRryEt+ISiEF0jK7yVw0BJA8pf7YeL1Mwid5 vKLK3PFkHTeNcK9WYruVb82eoeGzNW+a76CNj9vV5q4Hl96q/a1fhHRIedl1tDO0qO2uHjkq X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:133150 Archived-At: Alex 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.