From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#34708: alist-get has unclear documentation Date: Tue, 12 Mar 2019 17:08:58 +0100 Message-ID: <87va0oyt0l.fsf@web.de> References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> <87mumcdu7f.fsf@web.de> <875zsyhakx.fsf@ericabrahamsen.net> <87fts2h9we.fsf@web.de> <871s3mh85d.fsf@ericabrahamsen.net> <874l8iebyz.fsf@web.de> <878sxui7bo.fsf@ericabrahamsen.net> <87va0xcxco.fsf@web.de> <87h8chey12.fsf@ericabrahamsen.net> <60367f47-c0b0-45b4-8ccf-169044400a75@default> <8736ntmsy3.fsf@web.de> <3af3b645-84e0-4208-be48-810e8cd2cfa8@default> <87wol5l6xk.fsf@web.de> <6e0c5a88-34db-4957-9cc5-98a14ae64f9f@default> <87ef7c1bxs.fsf@web.de> <32eea01e-cec1-42b7-8221-f4dd4652f0fa@default> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="244038"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Eric Abrahamsen , 34708@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 12 17:50:34 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h3kbq-0011O4-C7 for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Mar 2019 17:50:34 +0100 Original-Received: from localhost ([127.0.0.1]:55771 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3kbp-0007tK-86 for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Mar 2019 12:50:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3jyd-0006IQ-DP for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 12:10:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h3jyc-0006BD-Iz for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 12:10:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55171) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h3jyc-0006B6-Cx for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 12:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h3jyc-00040E-60 for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 12:10: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: Tue, 12 Mar 2019 16:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34708 X-GNU-PR-Package: emacs Original-Received: via spool by 34708-submit@debbugs.gnu.org id=B34708.155240696115320 (code B ref 34708); Tue, 12 Mar 2019 16:10:02 +0000 Original-Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 16:09:21 +0000 Original-Received: from localhost ([127.0.0.1]:40478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3jxx-0003z2-KN for submit@debbugs.gnu.org; Tue, 12 Mar 2019 12:09:21 -0400 Original-Received: from mout.web.de ([217.72.192.78]:35569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3jxu-0003yn-SH for 34708@debbugs.gnu.org; Tue, 12 Mar 2019 12:09:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1552406939; bh=nn9dFWJUFJFeawE1WX/ylBI6wjPJKb3/Entxk6rPLyE=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=RnHz2yDglUE5jpjjyZaXfSynufojumrJFD4RoWsr3DMHBTyo9tp9jWrPqxjQMNH2h b+QkalMB7HrnPdVUWQlUuUde9nGBLUKBMAe0s/COcHCKhhM5oFUsopN/gGr4b7YPnw cNmHh3R08khQq95bZjPd2/4aiunwLwxBJT1e0xQ0= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Original-Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MHGil-1hG8IT4Bbn-00E8Zd; Tue, 12 Mar 2019 17:08:59 +0100 In-Reply-To: <32eea01e-cec1-42b7-8221-f4dd4652f0fa@default> (Drew Adams's message of "Tue, 12 Mar 2019 07:48:27 -0700 (PDT)") X-Provags-ID: V03:K1:Vp2N6GjT4EZYK1DzuV48fBkmlIx7Hya2veEARP+0ToJyK/CsWV0 OhLc47yThMLYr3LMpsInN2b/atci83qwd1w6n9tiwo9XLn4T7w+tyy7e08lE5v+EqrfZuR6 f14pv7sJQBAfx93JuKdOCfGCABMk+8q3E6/oF3eFH41iFszWJYeBrpqFftVgnR/J/aZ7ihk EpGKjpu5osS3dspymxOoA== X-UI-Out-Filterresults: notjunk:1;V03:K0:B8EHEHHP6G4=:NGecLjlWH110X3MEMn8XIT 3hcRWdkR6t/Nh9+8KWMRtIXsuR8ksGzi88q1++KkgC4I/HPmpszYGLi8w3Jza4LnciVfaRxLk oKWQKzVpQfwhomSs5oAr2DMaYap0xJ/9gLuDEyyRZkbWBGCWsQzB1TQ4PHox89hYFAJ3UNKkq KzXa3TK8ncsbWcpPFb1jAjPvTO7hzzvoLWilHwkMrn2V8sbredDgT9JfP510DJKxkeqjHIVVc xDCtRmEivOdUhRIEAG+1Z2wC9HokeE5zK6uTmFSIvQ7RCkn/pmurj1rQd/dz5atCO8A6N6c5V 0zWiTVc31My4dn8A3X63yLkH9Drk7wVJzqsEAcqNhKR4LXh3KZpfBtffPcfXQW3ewaa1NHTTP cr78BXyN91vt6BrX8aidG8GApIuW45KqXIckOPJKGbVrbzvmVXqCD65VNWxsivJNGt5wanJtz nK4MCW248sTLe0T9vHfLZ9YhDMplmRJntmPlP9XZBXmZe86Xs8mzb0Ji3bGYjt3mv+fjjvnsM sxGfbMEnR3fUKiK95bJWgjCZhxq1QUPxM1DYM9KQwoNG36rL93Y1bzvy+wxS0NihjI2J3sTF5 y8LWLXI96WIdWinfOt7wBDR9Al1vZ3WFzXU1ViGewHqFBEJrDhmjVNnMPMOFox10fihddK+yj tg8sbXl29zot2ysT0WWR39dN06GK8PBuO9C1+w1IPoy4ZRu9ClF2U25efUvoQFsra3bfHaGVY XHwHAUkZuz2oBgHyyJx/whY2piYkWtF8lHMttbq9CxqaPz7a0NKknoPSBfSJBZGSBJ5MCP2N X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:156269 Archived-At: Drew Adams writes: > > Yes, in these cases eql is not useful. > > But they are the more common cases, I expect. > The cdr of a list is typically a list, not an > atom. > > If this is the case then it's an argument for > the default being set to `equal', not `eql'. An argument against changing the default is that `equal' is slower. > My question in that case is why REMOVE is made > to work this way? Normally, alist element > lookup/identification is by key only (or value > only). To look up both key and value it's > `member', not `assoc' (or `rassoc'). As I said: otherwise it would not make sense with `setf'. I think you have a wrong expectation of what the implementation of alist-get as a place expression is trying to achieve: It doesn't want to implement each and every way of modification operations for alists. It simply implements the most straightforward way of what setting such a place could mean. First of all the expected semantics of setf should hold. In one, special, case - when setting the place to the default - setting the place can be achieved by removing an association from the alist (because after removing the association DEFAULT is returned by evaluating the place expression), but it's only done if explicitly requested by providing an extra argument. If you don't like using it like that, just use something else. > That's an operation on general list elements; it's not so much an > alist operation. Why is removing an association different in this > regard from adding or changing an association? Why does it need both > key and value? As I said: because setf requires you to specify a value, and it only makes sense to remove an association if this value is the DEFAULT. Else the value in (setf (alist-get ...) val) would be ignored. That would be nonsense. > > You only seem to think of one case: I have a variable x which holds an > > alist which I want to manipulate. There are more cases: the alist > > place > > could be a real nontrivial place. > > How is that a different case? But maybe I > don't have understand what you have in mind > by a real nontrivial place. Presumably > you're talking about an alist with complex > elements? No, I was talking about complex (nested) place expressions referring to an alist. Michael.