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: Wed, 15 Mar 2023 03:13:57 +0100 Message-ID: <875yb2oj6i.fsf@web.de> References: <875yb7vijp.fsf@gmail.com> <87sfeaj0tv.fsf@web.de> <87edpufqkr.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="2703"; 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 Wed Mar 15 03:15:18 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 1pcGfe-0000Tp-BK for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Mar 2023 03:15:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pcGfU-0007sk-6p; Tue, 14 Mar 2023 22:15:08 -0400 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 1pcGfO-0007sL-TG for bug-gnu-emacs@gnu.org; Tue, 14 Mar 2023 22:15:02 -0400 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 1pcGfO-0002eJ-HP for bug-gnu-emacs@gnu.org; Tue, 14 Mar 2023 22:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pcGfO-0004Hq-8T for bug-gnu-emacs@gnu.org; Tue, 14 Mar 2023 22:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Mar 2023 02:15: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.167884644616397 (code B ref 62117); Wed, 15 Mar 2023 02:15:02 +0000 Original-Received: (at 62117) by debbugs.gnu.org; 15 Mar 2023 02:14:06 +0000 Original-Received: from localhost ([127.0.0.1]:38813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcGeT-0004GP-Q8 for submit@debbugs.gnu.org; Tue, 14 Mar 2023 22:14:06 -0400 Original-Received: from mout.web.de ([212.227.15.14]:60879) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcGeS-0004Fm-Mk for 62117@debbugs.gnu.org; Tue, 14 Mar 2023 22:14:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1678846438; i=michael_heerdegen@web.de; bh=9jNvUvYgXApmrQym+SjJMA46hB8gvk0Q/ktsElJSlCE=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=R27AdOi3OpoAbOON4uCsoxJEi9mQJ8p209BDwvxMUjMKAnQHxlw9AuUQLIUcLDTvC cdpN8o4x1jS6zFoQIy+xvuf/eaZBMWCowgodrxnNdobU4zZgjGJze+O0HlCkwyjHbE +IsKREyq+qO1kXUzaZSWHD4I/ERu142Vlos6VO3Qkz5kzSyDuu58tSiVce3/KNXmHc 8U95HvpwZtJG7ESn3z1AiCPEK5lYKPvaZHJc6IyjnPLNagyQHNGTkAYwIaPtr5OBp5 1T4elktn86Q30rtmAvnKqVkTLo3ofehHjc8a8FdkGUOMGzL6GB3Dh6uFtuAQkMKyax NTEdjyEYDsC9Q== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from drachen.dragon ([178.14.74.146]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1Mhnvw-1q7Dgk0ODA-00e5Ef; Wed, 15 Mar 2023 03:13:58 +0100 In-Reply-To: <87edpufqkr.fsf@gmail.com> (Augusto Stoffel's message of "Sun, 12 Mar 2023 07:09:56 +0100") X-Provags-ID: V03:K1:rqEsyctSwagEa3PuzWtKNbW0NbcEibiKzTsg5zsvysvIQBVJ9Qr Qp0+nZImBtXFb6OqP+OzMPos0xiiT0Gyz11antlipJaVLSHdk6EFBvXoQMEmhDpb5GdG3YX 7EqJiOPsToK44R2RxQbnQQvyuuYP42dDNqBMMRCwb+LdzT6VYIIVsCePeW1K4wHf63IdvbZ mrnqWvpo+ZzRgIFcLBTMg== UI-OutboundReport: notjunk:1;M01:P0:3WWeGHg2JOE=;gToc6avr6UlC4lxAF6M77Vorpi+ 8D8aVLxtodmQeCNGDJOZdQ1iPv3dVFZ6in4Ep/kA/jl4pWqlr2ojE7Q0uWTKon+u9UF0jvDVA prPVPZB7w83kNdtrKnwghFICg9wZ0d8JtTX3eFM+v6EC9kH10TCC4ACT+c+o3hfXVp6rGt8Lj cTuJZnI3L9rL33u8hF3ay6+gHhRoEG+Tzg8s1MHfmGoJiDp7kIxB6uSAGBd3x4ChZMrlOOcgN w48k38+VQz8SK/Uv5kI9Z/3MIedK7QXUvbhbddGRGGI+dw3arepAu1ptftx5u0wOS68pbfxMv JNH3dS/l7b+MeSExMjuS1z3PKs4yZjgiJnwNaXubxQ9YWnYzLenloSFvrBT413GDdMMf+4o6H x0bOIvlkyCOo7x5ZtB7BpaMHQVw1qNkaq8O49cmYFH8FZhk6WN+Kkvx4UZPKcS9392DSpjtHn 6qoB6i4ZnzxWvoWXUhDCqRIykwR5Nx0v6XccSkOu7zuCic2sV8GIRYeq1qw+bo5Ez72zyJGa+ eI2zBJUnxeXT+7EbABIDDOw6UJKOeMaZtyJxA2kyjtFfY9KH3RA14NB4X0S0sKmTZ9e9uBK7Y jCp2YgIFNkPe7R347SnjmQ4+FLiyFVE2JD8Fr/GPS8ad0YrRM5CquUse0Gr2C1zSwKK1dWMK4 386+TYkoPUD+Z/hW3kGzw9VmYfL6EBRM2VwsNW9d4bxccmvqm6TZ/BAi8w7FqnVmMWRnLFiRv gudO+2QnJ89om9f7U6DAeEbpVNftXk6gT1EE/M/7RV5wCaV3ZwHhpMhjt4/3Ytnt639AQ+qz 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:257951 Archived-At: Augusto Stoffel writes: > >> 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. > > This is not right. map.el doesn't abstract away the nil entries. They > make a difference all over, e.g. in map-length, map-do, map-empty-p... Hmm - right, of course. For your original recipe, it would in theory help if the implementation of `map-put!' for hash tables would remove the entry if the set value is nil. But for the reason you gave, we probably don't want to do this. Unless maybe we do the same thing that had been done for `alist-get' and add an additional REMOVE argument to the generic functions `map-elt' and `map-put!' (I'm afraid that a lot of people that like using libraries such as map.el don't like using such an argument, though). `cl-letf' would still not be smart enough to distinguish the two cases (1) value was the default value and (2) there was no entry when restoring the gv binding. Michael.