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 14:04:15 +0100 Message-ID: <87ef7c1bxs.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> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="236920"; 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 14:06:21 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 1h3h6q-000zTQ-BT for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Mar 2019 14:06:20 +0100 Original-Received: from localhost ([127.0.0.1]:52229 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3h6p-0005J0-AH for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Mar 2019 09:06:19 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50392) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3h6e-0005Gu-T6 for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 09:06:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h3h6Y-0002PK-UE for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 09:06:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54522) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h3h6Y-0002OF-NR for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 09:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h3h6Y-0005Zu-E5 for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 09:06: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 13:06: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.155239591521384 (code B ref 34708); Tue, 12 Mar 2019 13:06:02 +0000 Original-Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 13:05:15 +0000 Original-Received: from localhost ([127.0.0.1]:39833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3h5j-0005Yj-2n for submit@debbugs.gnu.org; Tue, 12 Mar 2019 09:05:15 -0400 Original-Received: from mout.web.de ([212.227.15.4]:40243) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3h5c-0005Y0-JT for 34708@debbugs.gnu.org; Tue, 12 Mar 2019 09:05:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1552395856; bh=EVyD2gfG44790kNQbmr4nnLPCCNXSe9/ZcCVSj7/2WQ=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=Vz47BlBHFs2jrJfS41BbGoHZCi43SlxK0y3IFdZgq5+sxRfgZGrWCTyOpzhpxz2op PvNKKwabtShKLCM5c1O+uIOImNnUkd4kqUbIP3qAZmuPL+LLR7vkEvAMgE42ROow2E 4Mckq+UNzMfU1477hnwW27XtfD5bHPScs9Y3e9iI= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Original-Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb002 [213.165.67.108]) with ESMTPSA (Nemesis) id 0LyE3J-1gxpYA3Y29-015Ywv; Tue, 12 Mar 2019 14:04:16 +0100 In-Reply-To: <6e0c5a88-34db-4957-9cc5-98a14ae64f9f@default> (Drew Adams's message of "Mon, 11 Mar 2019 10:48:16 -0700 (PDT)") X-Provags-ID: V03:K1:mkr5/hwYO0DenZyCtFLzxCiifQmCIKeGkp5viDd2QXXErzd0GWJ vQvmlYGqY9ZjdVrijNam2TV7JPuP42aTCtg9O50a0xLCdp0lA2riCwq43UIDRbV2uSTjMsM ilacnx1zRnCOaxhKmZktpGhFm6CHf07QdMVK3Qu7kcV9zvLoQEbGU77IgT7bjU+16ENo/Kh 6XEaqZSLE9E+GrIwHEVgA== X-UI-Out-Filterresults: notjunk:1;V03:K0:n/mua3NLRq8=:p/6KTlMi58qCCuu7gRzGmB 1N7zEkXgTGvSCHWIYPnNUNfhLAOmnQTJD3gSBmJmgkpc+wpSinuMpYGc/hRXCKKwB3qUW87KT osj/Yrygi0I1+uKAKXWHJ6oD2Q7hNJJLWTlGDCqIRY7jiMtSFrmlN6quQzw17y2lHq9jsROgk nrs1aiTGBTgFTbGFo4uvL6xymqRUWmocHAUGDsAZFLq/A1rzy9P9andwjvu670Lx/N6CwNFxf 2Po0V9JrCAiMEvdc2kp56tUfnhYhqlreTG2y3X3edScyvlXZ/SdHv8Xx8QuiWBgvkJJzpx3z+ kaOt4BOj82yqN9RvqsZYReuWtGwJZ8qMjONbll1BFU6Nbzpoh5qrIaNQqNwI8vmfCTHJ068t+ T9ZpuBiQzHPeAZlci1fz3J0nAosTtmnXdenzC4IpRLfJZ8vnCu3xbuoeesnAnuN4Xyvm7eEky lF5Z7lfxirCwe6Qg1MuDEjsuJMsNBZcFwEve3EGjjFPIUxTBgGvqfFLpE9BfpL70t/U/hcNzc 8+BH2rKrK3afK8blQBUCBznzNWQKLP7RFR0589YV1egsza8tgACN4C/sg4QqZ4tB+X/fy9M2F oJ/IdCSJH2nV5SIxw9VZ9c3kAZGBV4bIbPfYDRUISmRVy1s5MFfoo2bMrhUaQHFNdtS+kQnHB oJW2BXN6emdZKkClqQntEu2eNot+LRkU3q8ydPeRGuQOjYiBD5dUMCkY6PJlB2r9A1sc9048w gz9BtBkSS6gPHfK0Ph6eIP3qZQRzWimRbCaBeWdM3ug4Cde8HgQEVppC/ipQhsNMpiGg8X3n 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:156258 Archived-At: Drew Adams writes: > > > > I wonder if there are use cases where the user wants something > > > > different than `eql'? E.g. `equal' when the associations are > > > > strings? Note that this is something different than TESTFN > > > > which is for comparing keys. > > > > > > I think so, yes. Why wouldn't we want to allow that? > > > > To not add one more argument? > > An _optional_ arg. Why wouldn't we want it? Because it would be one more argument that only has a meaning in place expressions. > BTW, how does `alist-get' deal with a value that is > a list: `(a 1)' instead of `(a . 1)'? I guess it > just considers the VALUE to be `(1)'. Yes. > If so, is `eql' really appropriate for most such cases (which are > quite common)? > > And even for `(a . (1 2))', aka `(a 1 2)', is `eql' appropriate? > Since the cdr of a list is more typically a list, why would we choose > `eql' as the default value-comparison predicate? To compare lists the > default predicate should be `equal' (or possibly but not likely `eq'), > no? Yes, in these cases eql is not useful. > > > > (2) The remove feature has a strange corner case. Normally the > > > > first found association is removed, > > > > > > So "normally" it's really "remove one". > > > > > > Why is this? What's the point of REMOVE - why is > > > it needed (added to the design) at all? Is it to > > > provide a way to remove all entries with a given > > > key or only the first such? > > > > The first. > > Then why did (does?) the doc say "if the new value > is `eql' to DEFAULT"? It sounds like it removes > only the entries with a given key AND a given value. It removes the first entry with given KEY and value eql DEFAULT. BTW; I suggest to have a look at the code in gv.el. > Anyway, if that's all REMOVE does (removes all > occurrences), and if it can be a predicate, then it > sounds like it just does `cl-delete-if'. > > If so, what's an example of why/when someone would > want to use `setf' and `alist-get' to remove entries, > as opposed to just using `cl-delete-if'? You can also cl-delete-if, yes, there semantics overlap. OTOH cl-delete-if doesn't support generalized variables. > Then isn't it a bit misleading for the function name > and doc to suggest that this is a general way of using > alists? I don't get that impression from the doc. For the name: what else would you suggest? This _is_ the general way of getting associations from an alist. You can also use it in place expressions where it is convenient, you don't have to, of course. It's in the nature of place expressions that there use is a bit limited compared to what you could do with general lisp. I see no problem here. > So far, I guess I don't see the use case for making it a generalized > variable. It's easy enough to set alist values, and doing so with > `setf' and `alist-get' sounds more complicated, not less. > > For getting, I think I get it: folks apparently don't want to get the > full element and then dig out the value (cdr) from it. (Is there more > to it than that?) For setting and removing, I don't get the > advantage, so far. 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. And you can not only use setf on alist-get places, but all macros that handle places, e.g. incf or callf or letf or ... There are surely cases where using alist-get in a place expression can be handy. Nowhere is said that you should use alist-get only and always when dealing with alists, especially for manipulation. > > One thing I don't find consistent is the case where the alist already > > has multiple occurrences of a key. E.g. > > > > (setq my-alist '((a . 1) (b . 2) (a . -1))) > > (setf (alist-get 'a my-alist 1 'remove) 1) > > my-alist =3D=3D> ((b . 2) (a . -1)) > > > > (alist-get 'a my-alist 1) > > =3D=3D> -1 (!) > > > > One would expect 1, of course. > > Why? The doc says that it returns DEFAULT only > if KEY is not found in ALIST. But entry (a . -1) > finds `a' associated with -1. What am I missing? Think from the viewpoint of places: I have set the place to 1. Then I expect that I get 1 when evaluating the place expression afterwards. > (setq my-alist (cl-delete-if > (lambda (entry) > (and (eql (car entry 'a)) > (eql (cdr entry 1)))) > my-alist)) > > more straightforward than this: > > (setf (alist-get 'a my-alist 1 'remove) 1)? Depends on your taste, I guess? > `alist-get' specifies an alist entry (a single one, BTW). `setf' of > `alist-get' should set/create an alist entry (a single one, BTW). > Otherwise, we're abusing the intention of one or both of these > "functions". No? I indeed see that point different, yes. The remove syntax when using it as a place is not super sexy (no one says you have to use it for that btw), but I don't see what you write as a requirement. When not using REMOVE it's all very straightforward in my opinion. Michael.