From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#34708: alist-get has unclear documentation Date: Mon, 11 Mar 2019 07:52:31 -0700 (PDT) Message-ID: <3af3b645-84e0-4208-be48-810e8cd2cfa8@default> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="109540"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Eric Abrahamsen , 34708@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 11 16:00:19 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 1h3MPb-000SJH-8x for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Mar 2019 16:00:19 +0100 Original-Received: from localhost ([127.0.0.1]:34805 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3MPa-0007Cw-35 for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Mar 2019 11:00:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34621) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3MMb-0004j8-4s for bug-gnu-emacs@gnu.org; Mon, 11 Mar 2019 10:57:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h3MIY-0000Fa-B6 for bug-gnu-emacs@gnu.org; Mon, 11 Mar 2019 10:53:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54036) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h3MIY-0000FU-35 for bug-gnu-emacs@gnu.org; Mon, 11 Mar 2019 10:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h3MIX-0002IP-RT for bug-gnu-emacs@gnu.org; Mon, 11 Mar 2019 10:53:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Mar 2019 14:53:01 +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.15523159628799 (code B ref 34708); Mon, 11 Mar 2019 14:53:01 +0000 Original-Received: (at 34708) by debbugs.gnu.org; 11 Mar 2019 14:52:42 +0000 Original-Received: from localhost ([127.0.0.1]:39347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3MIE-0002Hr-Do for submit@debbugs.gnu.org; Mon, 11 Mar 2019 10:52:42 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:37286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3MIC-0002Hd-Ix for 34708@debbugs.gnu.org; Mon, 11 Mar 2019 10:52:41 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2BEhiSl179433; Mon, 11 Mar 2019 14:52:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=MfX0qMuNO1yGVpUCaskByV1dP3r0Mg+KffP+Dm8LQjM=; b=TOmDDswB/H1ko/gkCtVd8fTO09c8lNcGaX7fpFr4AdXBCUctRuHnoeFFGi4ilEgeG/nR Z3waOYLh2f9mfbKcTZEGJsXlXiiw2ehE00ftRC+NH/g29byTkkYCDihtgADJzEthiScB PlZ3OpiL5Je0vxhnPQdckYeLAcaPvFYbyaE3L0lpwu4oiQtTOlh4P+UsCstFmNQwVz3o eqgkkXGOMo3fXu9+HgB4zqhB3zbX7ySdBOk0BSR8mORrsxtP7DwhTuFxUz9D3vCIgDXf XpeZgjx7urou9xEUIL5h3SxNALCOF47pYJParZIskmlJF4sPpkhrWdTMV6Ba69i897cL gg== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2r464r6uvs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Mar 2019 14:52:33 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x2BEqXNh015351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Mar 2019 14:52:33 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x2BEqWdF019623; Mon, 11 Mar 2019 14:52:32 GMT In-Reply-To: <8736ntmsy3.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4810.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9192 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110107 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:156234 Archived-At: > > Alists can be handled in more than one way when > > setting and deleting keys. The doc needs to tell > > us what `setf' with `alist-get' does to realize > > these things. >=20 > I agree. > I'm in the middle of preparing a patch. While doing that, two questions > arose: >=20 > (1) "When using it to set a value, optional argument REMOVE non-nil > means to remove KEY from ALIST if the new value is `eql' to DEFAULT." >=20 > 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? > (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? If we want to provide for pretty much everything that one typically does with an alist (without `alist-get') then don't we need to provide for the ability to do any kind of removal - or other operations - on alist elements that have a given key? Should "set" and "remove" operations not (at least be able to) obtain the _full_ sequence (in entry order) of such matching elements, and then perform specific operations on that sequence (such as setting or removing the first one, the Nth one, or all of them)? If we were not trying to allow `alist-get' to be usable as a generalized variable then I suppose we wouldn't need to worry about any of this. Likewise, if we weren't trying to provide something for alists that lets you use alists as alists (!) then I suppose we wouldn't need to worry about any of it. IOW, if we were limiting `alist-get' to hash table-like behavior (e.g. a single entry per key) then none of these questions would need answers. But if we are really trying to provide _alist_ manipulation then yes, I think we need to consider such things - find reasonable ways to provide for all of the usual alist manipulations. I'm not sure what the motivation for `alist-get' is/was. I suppose it was to provide a simpler way to interact with (manipulate) alists. It's not clear to me that there is a simpler way than what we've always been doing, IF, that is, we try to provide for setting, testing, and removing, in all their generality, and not just getting. IOW, I'm thinking that _getting_ an alist entry is pretty straightforward (though even in that case someone might want to get the 2nd or Nth such, and not just the first), but that setting and removing are not necessarily so straightforward. It would be good to see a statement/spec of what `alist-get' is trying to accomplish, especially wrt setting, testing (diff predicates), and removing. > but if you somehow manage to add the same > cons (in the sense of `eq') to the same alist, all > of them are removed. Compare e.g. >=20 > (progn > (setq my-alist '((a . 1) (a . 1) (b . 2))) > (setf (alist-get 'a my-alist nil 'remove) nil)) > ;; my-alist =3D=3D> ((a . 1) (b . 2)) > vs. > (progn > (setq my-alist '((a . 1) (b . 2))) > (push (car my-alist) my-alist) > ;; my-alist =3D=3D> (#1=3D(a . 1) #1# (b . 2)) > (setf (alist-get 'a my-alist nil 'remove) nil)) > ;; my-alist =3D=3D> ((b . 2)) >=20 > This is because the code uses delq to delete a found cons, and delq > removes all `eq' elements. >=20 > Is it worth to document or change that? Sounds like an implementation/design artifact. If that will stay as part of the design then yes, I'd say such behavior needs to be documented.