From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#55645: src/print.c; print_object changes make it impossible to compare elisp code across versions Date: Sat, 04 Jun 2022 12:15:26 +0300 Message-ID: <83czfobxht.fsf@gnu.org> References: <87zgj4biw7.fsf@gnus.org> <874k1b9ser.fsf@gnus.org> <874k1a54ap.fsf@gnus.org> <87o7zg1nut.fsf@gnus.org> <83v8tojrr5.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7302"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 55645@debbugs.gnu.org To: Tom Gillespie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 04 11:16:40 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1nxPtg-0001jo-1p for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jun 2022 11:16:40 +0200 Original-Received: from localhost ([::1]:55678 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nxPte-0002N5-RK for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jun 2022 05:16:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41420) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxPt6-0002Ms-DA for bug-gnu-emacs@gnu.org; Sat, 04 Jun 2022 05:16:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35514) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nxPt4-0000ck-LO for bug-gnu-emacs@gnu.org; Sat, 04 Jun 2022 05:16:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nxPt4-00084J-ED for bug-gnu-emacs@gnu.org; Sat, 04 Jun 2022 05:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jun 2022 09:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55645 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 55645-submit@debbugs.gnu.org id=B55645.165433415030995 (code B ref 55645); Sat, 04 Jun 2022 09:16:02 +0000 Original-Received: (at 55645) by debbugs.gnu.org; 4 Jun 2022 09:15:50 +0000 Original-Received: from localhost ([127.0.0.1]:57644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxPsq-00083o-6S for submit@debbugs.gnu.org; Sat, 04 Jun 2022 05:15:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxPsl-00083a-Hd for 55645@debbugs.gnu.org; Sat, 04 Jun 2022 05:15:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47586) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxPsf-0000PO-Si; Sat, 04 Jun 2022 05:15:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jRIwfGna4w9t/pRlU9KnKTMn1DmX09gWLuLnRB7tQzk=; b=Iw7WV32wKLW/ ob9W2RadvwOGlxRFR9M6oz0hm03B0L65e12qOutihVFEGsEhohGu9xNbTHbuicQadS7jGVp97CbRL pQ/KJGr2jfcb2i95+iegah35SRTlMo3HyXDUT8EumWGPJGXH74jnZc0Swbc6/5uLjIwznb3aoTNH5 w9wsTgis7tZeWGeQQrKLKKvU/iUnCtX1aFzN3igRG0hyNVGbyDgzkaqhydLpAlhkUOsPIWeUgswff r/GrGCxk7rlmwaTtCjtsrJzdOpUajp2yK9r+bQi2vU0QQ5H3Do5KrgJ0lcjS9dDGn5HP//thjuQmM xdt9HnGM2TFQrK0+mrTs9Q==; Original-Received: from [87.69.77.57] (port=4506 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxPsa-0007m4-LS; Sat, 04 Jun 2022 05:15:34 -0400 In-Reply-To: (message from Tom Gillespie on Sun, 29 May 2022 14:03:11 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:233642 Archived-At: > From: Tom Gillespie > Date: Sun, 29 May 2022 14:03:11 -0700 > Cc: Lars Ingebrigtsen , 55645@debbugs.gnu.org > > Hi Eli, > I have included an example below, with some additional context. Best! > Tom OK, thanks (and sorry for the delay in responding). I think I understand the issue now. You say in your OP that there's no way to work around the issue, but I wonder if this is really so. It seems to me that by adding a backslash before '.' and '?', before computing the hash, would be one workaround? > The example below works on emacs-18 (had to remove the number 1.0 > example because emacs 18 does not have support for reading floats). > > The output of this code is unchanged from emacs-18 through emacs-28, > however it is now different in emacs-29. > Emacs 18-28: > "(progn (+ 1 2) (a b\\.c d) (defun hello nil world)) (progn (some > elisp code I want to normalize\\. That has strings \"1.0\" and symbols > a\\.b))" > Emacs 29: > "(progn (+ 1 2) (a b.c d) (defun hello nil world)) (progn (some elisp > code I want to normalize. That has strings \"1.0\" and symbols a.b))" > > #+begin_src elisp :tangle /tmp/example.el > (defun normalize-elisp-code (body) > (let (print-quoted print-length print-level) ; proposed variable > would be added here > (prin1-to-string (read (concat "(progn\n" body "\n)"))))) > > (defvar example-body-1 "(+ 1 2) (a b\\.c d) (defun hello () world)") > (defvar example-body-2 (prin1-to-string '(some elisp code I want to > normalize\. That has strings "1.0" and symbols a\.b))) > (message "%s %s" > (normalize-elisp-code example-body-1) > (normalize-elisp-code example-body-2)) > #+end_src > > The additional step in my use case is the checksum, which cannot be > read back in, and changes from 28 -> 29 due to the differences in the > output of prin1-to-string seen above. > > #+begin_src elisp > (defun checksum-elisp-code (body) > (secure-hash 'sha256 (normalize-elisp-code body))) > > (message "%s %s" > (checksum-elisp-code example-body-1) > (checksum-elisp-code example-body-2)) > #+end_src Frankly, I'm amazed that someone could have such faith into immutability of Emacs Lisp. Why would you assume that the above produces the same literal string across versions, especially given everything that happens lately in Emacs, including changes in the byte-compiler, the introduction of native-compilation, etc. If someone would show me a design that is based on this, I'd tell them they place their bet on a dubious horse, and suggest to find a better design. To me, this is taking some Emacs feature that just happened to be stable, and assuming it will forever be stable. There's no reason and no real basis for such assumptions. Thus, I agree with Lars that it is strange to hear that prin1 is used as something that's supposed to produce a canonical representation of Lisp code; it's definitely isn't its purpose. Anyway, one way forward is to add a new API specifically for that purpose, and then guarantee that the output of that new API will be stable. This will also take care of the issue with the design that relies on prin1. Another way forward is to revert the change. And here I'm asking Lars what are the reasons for the change, except some aesthetics-related considerations, whereby we basically didn't see why the escapes are needed. If the only problems are that we didn't see a good reason for keeping the escapes, perhaps now we do have a good reason? Thanks.