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: Sun, 26 Dec 2021 15:35:35 -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="25374"; 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 Sun Dec 26 21:36:46 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 1n1aG5-0006Od-Ef for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Dec 2021 21:36:45 +0100 Original-Received: from localhost ([::1]:45822 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n1aG4-0004VJ-AW for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Dec 2021 15:36:44 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35934) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n1aFD-0003Ni-9U for emacs-devel@gnu.org; Sun, 26 Dec 2021 15:35:51 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48164) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n1aFA-0000pg-HT for emacs-devel@gnu.org; Sun, 26 Dec 2021 15:35:50 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C6769100312; Sun, 26 Dec 2021 15:35:44 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 28CE0100224; Sun, 26 Dec 2021 15:35:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1640550943; bh=k41hNUjY24sejBcB0y8UQvlk2TTMhl/o0b/3QLbN0yk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=bpxdc/Ewiv9e5nz1vKjl8posO0QDlOeNVTtZQCz6As375q6F1aim1lwYLMcZmsGJ0 5RlLZVq/05lGrYEwDZIpoqk3aAdrnDxQ0zBmFZw4LHekRTcFhzrcV3us23PKevhFO7 aONlK0cUNIYG16LLzZe53vEbfdlNkf/1dp4mvLr2edNF3O3PvitcgT4EkLXLPaksyH 8S+6+piSeND1iyY3lvfex0GjkrF4EV/0PcWg1sJS04GT3OpLCzeloi4WIAygcbSWc3 W+QuWuOYGneQye0rYxNg2DJUnwcs7+IZdRw45TFHwFGmkYcEiUWghAoYy6iQ/LuL9V o+z0Q6aWt4WFQ== Original-Received: from ceviche (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EE08B1201BE; Sun, 26 Dec 2021 15:35:42 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Fri, 24 Dec 2021 20:37:49 +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:283350 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. >> 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. > > byte-compile-strip-s-p-1 has been enhanced to handle records, too, > though I haven't committed that bit yet (along with quite a lot of other > amendments, too). Hmm... now that I think about it, you only generate symbols-with-positions (symposes) when byte-compiling, right? And you can restrict this to the case where we byte-compile into a file (as opposed to the rare case where we just call `byte-compile`). So the symposes can end up in 2 places: - in the .elc file: no need to strip the pos here, just make sure the symbols get printed without their position. - elsewhere: that's the problematic part because this only occurs where the source code gets stealthy passed elsewhere, e.g. when a macro calls (put ARG1 'foo ARG2) during the macro expansion (rather than returning that chunk of code in the expansion). Here we don't have much control over where the symposes end up and I don't think `byte-compile-strip-s-p` can help us (unless we call it before passing the result to the macro, but I don't think that's what we want to do). So where/why do we need `byte-compile-strip-s-p`? >> 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. > I've tried the list approach (using memq to check for an already > processed cons/vector/record. It fell flat on its face with > lisp/leim/ja-dic/ja-dec.el, which has a list with over 60,000 strings > in it. Oh, right, we have to add to the list all the conses rather than only the head conses, so you definitely want to use a hash-table. Stefan