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: Fri, 24 Dec 2021 08:56:56 -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="29068"; 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 Fri Dec 24 14:58:50 2021 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 1n0l5t-0007Ii-Li for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Dec 2021 14:58:49 +0100 Original-Received: from localhost ([::1]:33432 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n0l5s-0002Fg-Oi for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Dec 2021 08:58:48 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n0l4J-0000zg-6j for emacs-devel@gnu.org; Fri, 24 Dec 2021 08:57:14 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64492) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n0l4G-0000iH-D7 for emacs-devel@gnu.org; Fri, 24 Dec 2021 08:57:10 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 62D0E440FA2; Fri, 24 Dec 2021 08:57:06 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 99AFF4412B7; Fri, 24 Dec 2021 08:57:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1640354224; bh=aSaxwnezZM36C+oOqf2Wo5u0n+PQ7kWvDx9bzeQmltc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=CF89sX7ahNAd+hL++jELbY08EH8dIwU+4xpHNQYXsfoI2GGFd1t+lmOFW3eO4/fj4 IXV9bStUKjjjl1l8GS4OCkW8fx97oaABCFUHCAPsIcAGIrPk8QHj3NxPgXmMPVG3gu AAYkhI6U9IHrTyGF2Gb433SHKI1C9gt4yanreQ7KO8Au0D2GHUYJYT7HT1AXzMXFav E76L/trnZ8QyOWuvRoowz9hGRyA+CYig5Kdi/b1dcUGia7k1lb0Nt00GuNIyF3Gyvv pY5dWahwr0LbEhguLrIZ0od6hHHVq3FmAm4pX2g0v/aVyCeldp0mmlg3CeQy3RoWLs KwYy2VrJ7Fe2Q== Original-Received: from pastel (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 65805120193; Fri, 24 Dec 2021 08:57:04 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Thu, 23 Dec 2021 21:15:16 +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: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, 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=ham 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:283146 Archived-At: > The recursion was in the (new) function `byte-compile-strip-s-p-1' > (where "strip-s-p" stands for "strip-symbol-positions"). This function > recursively descends list and vector structures, stripping positions > from symbols-with-position it finds. > > However, I seem to have circularity in a record structure, where two > records seem to point to eachother. I suspect that it is the zeroth > elements of these records (which are meant to be symbols) that are > pointing at eachother. 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)? Also, I see in `byte-compile-strip-s-p-1` that you only look inside conses and vectors. So I'm not sure what makes you say the recursion was in records since records are similar to vectors but aren't `vectorp` so AFAICT your code won't recurse into them. Also that means your code won't handle the case where the source code includes literal hash-tables, literal records, literal char-tables, literal strings-with-properties, ... These are quite rare and maybe it's OK to disallow them in source code, but maybe a more robust approach would be to make sure your lread.c code doesn't generate symbols-with-positions within anything else than conses and vectors? [ Tho it wouldn't prevent a macro from expanding into a literal hash-table from source that only has conses&vectors :-( ] > Would somebody (?Stefan M, perhaps) please suggest to me how I might > efficiently cope with these circular structures. Do I need to maintain > a list of already encountered Lisp Objects, somehow, and check this list > before recursing into the function? That's what we do elsewhere, yes, except that history taught us that a hash-table is a better choice to avoid scalability problems. Tho in your case you'd only need to keep the stack of objects inside of which you're currently recursing, so maybe a list is good enough. BTW, instead of doing it by hand, you can call `print--preprocess` which will do the recurse-and-fill-hash-table for you. You can see how it's used in `cl-print.el`. Stefan