From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#62117: 29.0.60; cl-letf on a map place has side-effects Date: Sun, 12 Mar 2023 01:00:12 +0100 Message-ID: <87sfeaj0tv.fsf@web.de> References: <875yb7vijp.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14754"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 62117@debbugs.gnu.org To: Augusto Stoffel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 12 01:01:20 2023 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 1pb99L-0003cX-HK for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 12 Mar 2023 01:01:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pb997-0000dB-4x; Sat, 11 Mar 2023 19:01:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pb994-0000cs-TS for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 19:01:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pb994-0001DS-LT for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 19:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pb994-0004Tf-3q for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 19:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Mar 2023 00:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62117 X-GNU-PR-Package: emacs Original-Received: via spool by 62117-submit@debbugs.gnu.org id=B62117.167857922717163 (code B ref 62117); Sun, 12 Mar 2023 00:01:02 +0000 Original-Received: (at 62117) by debbugs.gnu.org; 12 Mar 2023 00:00:27 +0000 Original-Received: from localhost ([127.0.0.1]:58820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pb98U-0004Sl-QW for submit@debbugs.gnu.org; Sat, 11 Mar 2023 19:00:27 -0500 Original-Received: from mout.web.de ([212.227.17.12]:38799) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pb98T-0004SV-4Z for 62117@debbugs.gnu.org; Sat, 11 Mar 2023 19:00:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1678579216; i=michael_heerdegen@web.de; bh=0vgylCGnGTpZvb9pw2Jsw/M2oFh+vE3FKCUCbb7PhVE=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=O2pYQns/71bEVaLdaxujeRJFPxoAba4qhYqsMT5WQymHNCzd8Te0Ox+9oDWGceLXz K1X7MMQtYogGCf4AnNZA4zUbUVRqcg6kSulWsOYPHafPh1tIffT+In1ZglozTfx4rE Sq71y2XS9Id48TgH1Q8j7NaEUYQZCdsVppKSncddl2YDO/oIzrZFyK+hs20gThttzs PGuTRgO0NM3USLKDDNUQim5PgBUKH9N0+FMOYQK4ippIK3S1OHOX5a/HyqAVMFKmjx 5FgMaZr3w4VbZORsEDxk1woLBC4TT7X2zF5wMFOOufO9k/QMajpyDo8IZ1jkpw4PpR VVaCv88eiTrUw== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from drachen.dragon ([178.14.74.115]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MLijy-1psoXf3k2a-00Hxp0; Sun, 12 Mar 2023 01:00:15 +0100 In-Reply-To: <875yb7vijp.fsf@gmail.com> (Augusto Stoffel's message of "Sat, 11 Mar 2023 08:44:26 +0100") X-Provags-ID: V03:K1:pgcjHaUHJ3nKwA8CsmU9599qs2MgSEVHqrIzbs0bVRSrAJD5IsP yuUj9h8Rs3jHDG1xLNjtlgL4VsF/URvgxHHeChQQSDfwinjn4tnwKjajmUsA6vWkiBLeOaN UDTyl9FhomqQ2RzGziYnO9/WeGP1RPDdMfngk89gqOVLmykLeh3h0PgMG+lAgFPF+VrhAt0 lO0POVnjmnnSz7F5W4FSw== UI-OutboundReport: notjunk:1;M01:P0:pAxk3R6wZMo=;qXk8lpVVUTaiNu6zH0krwW8G0C6 HnO/afpBtzDwsiDMnf3b2AmHOq4j1Zv8dLvHFWHCjEZnEuQQ+yjwZbzSwT6nAIyA0+pTIdASj J+fCF/fFMXDneFsQtOEl9LpKoRw0knP+JF5mfaqyA8jw0HKJO4vf1/M3k4mgvsmZmth4Lhc/M F0ajul98ZLp4avgu9Qx75p5Oy3WDmGjF8HwgyHFMpX5kbZ4MDVEdgZ634qKjXcJOg4sZX9GuV lpqZrCIBfCFQp9I/1M1nacxiZ0W67P8RtIqGoxsYALY01pgcHrwwZ4d115A+eFct+2AFuAPZu 3gq9J+d2cyn81+AhfnwvmdTYVGt3suLNpxvksacHirj1wM4UAr9sVTtZmToUy7xNWIp1zwkr5 LBBGBsvn3xwKIQyJ8QNPCReEByrBv8vQ7h1s6ZkefoprpQS/C33zksM6DPBM5RkIXKmL8givI XsoE8ELESKlFIEL7SmxBQs1HpDT5nXg/WqIii9015kAzlfcJruwyybQ7GmJsB3ERI6S9wg7qS ymWiwRBl4cLvswHRKJpHYZWMbzNBtPyH7M1bIGi50H44/RjVY8KSbyEwbFiTDbgARlML9E9C3 H9jWI4JJ+e3o+509xJXx5dyQdmUCq5vdhHlictjeeZFCVdCHFbNKA6VBDfqmT6m5TlWbhM6j3 aVrTilbHTt8/gWqLo83GXI4wO/BQoLb+jX2IC/r4piBuUR0e+bP/XZiyD1gxYBB0vd9wUvX1e OEKjzlBk+KGeBsrgsOPNSAvCIs2GF0RG0N9ttuBbm3V3+gXoCw3zoEtnE0GnUjHIuAE2HdV8 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:257825 Archived-At: Augusto Stoffel writes: > Consider this example: > > (require 'cl-lib) > (defun f (map) > (cl-letf (((map-elt map 'a) 1)) > map)) > > (let ((map '(b 2))) > (f map) > map) > => (b 2 a nil) > > (let ((map (make-hash-table))) > (f map) > (map-length map)) > => 1 > > > I would expect `f' to have no side effects, so get (b 2) and 0 > respectively in the two examples. This is a symptom of a general limitation of `cl-letf'. Currently you can't rely on a "no side effect" behavior. There are other examples like that (`alist-get') and cases that are worse (binding `buffer-local-value' of a variable in a buffer with no buffer local binding doesn't remove the buffer-localness - that's one reason why that gv had been deprecated). > Of course it's usual to treat a nil entry and no entry as equivalent in > Lisp, but this behavior can be a problem e.g. when constructing data to > pass to other programs. I would say: if it is a problem, map.el is the wrong abstraction for your case. That's the genuine idea of map.el: that the inner structure of a map doesn't matter. So I would close this one - unless you have some enlightening idea that would be an obvious improvement with no downsides and backward compatibility problems. Thanks, Michael.