From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Circular records: how do I best handle them? (The new correct warning position branch now bootstraps in native compilation!) Date: Sat, 01 Jan 2022 12:31:51 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7485"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 01 18:32:42 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n3iFF-0001jg-5t for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Jan 2022 18:32:41 +0100 Original-Received: from localhost ([::1]:42394 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3iFD-0000Wn-Qd for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Jan 2022 12:32:39 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:42600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3iEZ-0008Hl-5j for emacs-devel@gnu.org; Sat, 01 Jan 2022 12:31:59 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11536) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3iEW-0001On-9i for emacs-devel@gnu.org; Sat, 01 Jan 2022 12:31:58 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 101AA80552; Sat, 1 Jan 2022 12:31:54 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6B92280508; Sat, 1 Jan 2022 12:31:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1641058312; bh=04cXlTUPxeIwzU3+8tsC0IvJXT9kpJ1yj7vh3PzZNXQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Qfpnmvr0YupUT/qTpW11iHMU5+xJzJ12toGb4STQUFihRLvk6UBS0zy9XE5l4lnoT /H3P1vm1KMSSnuubv6gGOYsXygRkuBvFm7TfbCY4ZBWDta3Nu3ureljN+HW4ymji5h X3RMi/J1AaevoVMecSwDeXozv25OhTrvGVILbExDNVAghKMILEQsBdHHWMdsHipG9u XGSvOsPTfSdpsZnwGGKb69Qtt75LPs1V4bUvIgD4k9f4L9hFsX33noBB6dWj2wsEii 6PtnQf+3/oHwnB/TY6vL8UUv3aMHiCvBe+gJZBIUsOngT+OZokTdL2z4x3xBTlg/tA bQAy0MDcYKnqQ== Original-Received: from pastel (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3FE17120263; Sat, 1 Jan 2022 12:31:52 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Fri, 31 Dec 2021 21:53:22 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -22 X-Spam_score: -2.3 X-Spam_bar: -- X-Spam_report: (-2.3 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PLING_QUERY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:283803 Archived-At: >> >> >> Hmm... circularity is quite normal in data structures, yes. >> >> >> But presumably this is only applied to source code where circularity is >> >> >> very rare. Could it be that you end up recursing in elements which >> >> >> actually aren't part of the source code (and hence can't have >> >> >> symbols-with-positions)? >> >> > I honestly don't know at the moment. >> >> I think it's worth the effort to try and track this down. Maybe we can >> >> completely circumvent the problem. >> > I don't think there are any such cases. >> Hmm... I thought this whole circular records thread started because you >> bumped into such a case. I feel like I'm misunderstanding something. > What I bumped into was circularly linked vectors in the source code > being compiled. Then my question above turns into: what is this source code? > I've amended the reader so that it doesn't put positions on symbols > which are read as components of other structures such as byte compiled > functions, text property lists in strings, and so on. (Actually, there > was very little to amend.). OK. >> > The positions get stripped before the code is dumped to the .elc. >> Why bother? You can just have a `print-symbols-without-position` which >> you let-bind around the printing code. > I think I've got that already, though it's a long time since I looked at > it. So why do you need to strip the positions before dumping the code into the `.elc`? >> (defmacro foobar-really (arg1 arg2) >> (puthash arg1 arg2 foobar-remember) >> `(progn (do-something ,arg1) (do-something-else ,arg2))) [...] > In that (puthash arg1 arg2 foobar-remember), if the key is a symbol with > position, it is stripped. I think the value will keep its positions. > This might still be a problem. `put` and `puthash` are just some of the ways a macro's arg can "escape". A macro may also something like (push arg my-list-of-stuff) Having to strip symbol positions in `put` and `puthash` (i.e. having this implementation detail leak to those places which aren't directly related to compilation) is pretty ugly. Do we really want to extend that to `setq`, `aset`, and whatnot? Maybe we should "bite the bullet" and expect macros to announce whether they support sympos or not and if they don't we strip the positions before calling them (we can try to be a bit more clever by using the Edebug spec to find args where sympos will probably be harmless). >> > It's used all over the place. In eval-when/and-compile, it is used >> > before the evaluation. It is used before dumping the byte compiled code >> > to the file.elc, and before passing this code to the native compiler. >> > Several (?most) of the byte-compile-file-form-... functions use it. >> > It's used in the newish keymap functions near the end of bytecomp.el, in >> > byte-compile-annotate-call-tree, etc. Also in cl-define-compiler-macro, >> > and internal-macro-expand-for-load. >> Interesting. Why do you need it at so many places? >> What is it usually used for? > Stipping positions from compiled code before dumping it to an .elc file, That sounds like "one place" > and also before passing the compiled code to the native compiler. And that sounds like "a second place". In contrast above you list all kinds of *other* places. Why do we need to strip positions in those other places? Could we instead change the code (e.g. byte-compile-annotate-call-tree) so it works with sympos? > The fact is these positions on the symbols are unwanted for most uses of > symbols around compilation, being needed only in the analysis phase of > the source code. So you're saying the problem is that your compiler doesn't separate the front end from the backend? That's indeed an inconvenient of the current bytecompiler code. Stefan