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: Tue, 12 Mar 2019 09:48:11 -0700 (PDT) Message-ID: <84e7fa6d-7e89-4c7e-b94d-be40900a3422@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> <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> <87va0oyt0l.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="261492"; 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 Tue Mar 12 17:54:15 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 1h3kfO-0015l9-Ma for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Mar 2019 17:54:14 +0100 Original-Received: from localhost ([127.0.0.1]:55806 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3kfI-0002Ix-Bj for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Mar 2019 12:54:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3kaO-0006OQ-8Y for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 12:49:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h3kaM-0006YO-ON for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 12:49:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55197) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h3kaM-0006Xq-G1 for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 12:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h3kaM-0004wk-88 for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 12:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Mar 2019 16:49: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.155240930318971 (code B ref 34708); Tue, 12 Mar 2019 16:49:02 +0000 Original-Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 16:48:23 +0000 Original-Received: from localhost ([127.0.0.1]:40508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3kZi-0004vu-TE for submit@debbugs.gnu.org; Tue, 12 Mar 2019 12:48:23 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:56722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3kZf-0004vg-Tt for 34708@debbugs.gnu.org; Tue, 12 Mar 2019 12:48:20 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2CGhTQX094453; Tue, 12 Mar 2019 16:48:13 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=l2J/zlxAMfbXtBkY4cE52MNQ+ytdLIIIoLzpc31mRZA=; b=QNITTJTpD3pN5qIZZztP6YRf0Tb0OF8mGW5iEpcgLZy8ANdGpJOFLqHspZbHWl9TSRMM 0WS4e5bxjZ6CBFnr8ZqCetPKhEK8Ea2DgH8z5oQbMMyUcstw0K9blofjA/aua87zIw2i p3rckwfZEm6Fpu9zQ7RVW0IOGj8JQXKJWSETu0RyBEszTpQ5dIAe4xld/3c5js8UDsdR ajvWZhQ0G8aZuPJlD2YAAS9mKNv3s4HrEE/CftrYegozGyjIcL+sa8xkqvGUDZfaIJJF lE+uQL4WSlNo81AfnfHJ5Wqs5LUzCHL07OKyOPIFJZxrXNBYSx5S7S/ez5IyD/mpZ7Po TA== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2r44wu5ycg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Mar 2019 16:48:13 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x2CGmDFb017146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Mar 2019 16:48:13 GMT Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x2CGmBFY008304; Tue, 12 Mar 2019 16:48:12 GMT In-Reply-To: <87va0oyt0l.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=9193 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=927 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903120115 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:156270 Archived-At: > > > 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'. >=20 > An argument against changing the default is that `equal' is slower. I don't think such an argument would be a strong reason. And it's not even true for atoms. It is true for lists. But in that case `equal' is much more useful, I think (and I think you agreed, above), and is less surprising (a potential gotcha). > > 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'). >=20 > As I said: otherwise it would not make sense with `setf'. I missed where you said that, I guess. But what is your reason? Why doesn't it make sense for an alist to identify an element by just its key? Why expect both key and value for only this case (removal)? I missed your reason for that. (But I see you go into this a bit below, so see below.) > 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. How does "the expected semantics of setf" conflict with what I'm saying? How does it require the implementation (design really) of `alist-get' that you support? Maybe you're right, but I don't see an argument supporting that. > > 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? >=20 > 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. This is why I said that removal is not setting an `alist-get' place. Setting the value to DEFAULT would be setting the place. But removing the entry is not. Why have REMOVE instead of just letting users set the value (explicitly) to DEFAULT? That would really follow "the expected semantics of setf", with nothing funny going on, no confusion. `alist-get' is a function, not just a gv place. Argument REMOVE makes no sense for the function (does it?). All the other args do make sense for the function. Shouldn't all of the args to a function make sense for it? Should we add args that are only used by `setf'? Has that been done before? Adding REMOVE seems like a mistake, to me. I suppose I'm kind of acting as devil's advocate here, but I really do think, so far, that this is something odd and confusing. I'm looking for a good reason. If I hear it then it will likely all make sense to me. > > > You only seem to think of one case: I have a variable x which holds a= n > > > 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? >=20 > No, I was talking about complex (nested) place expressions referring to > an alist. I still don't follow; sorry. I guess you mean an alist embedded in some other list structure? Could you give an example, showing the advantage of having REMOVE? If you think I'm not helping then I'll keep quiet. I'm hoping that by trying to understand the rationale I'm helping a bit.