From unknown Wed Jun 18 00:25:49 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#34708 <34708@debbugs.gnu.org> To: bug#34708 <34708@debbugs.gnu.org> Subject: Status: alist-get has unclear documentation Reply-To: bug#34708 <34708@debbugs.gnu.org> Date: Wed, 18 Jun 2025 07:25:49 +0000 retitle 34708 alist-get has unclear documentation reassign 34708 emacs submitter 34708 "Miguel V. S. Frasson" severity 34708 minor thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 01 23:51:13 2019 Received: (at submit) by debbugs.gnu.org; 2 Mar 2019 04:51:13 +0000 Received: from localhost ([127.0.0.1]:56927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gzwcD-0005Zz-Dj for submit@debbugs.gnu.org; Fri, 01 Mar 2019 23:51:13 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gzwc8-0005ZZ-EK for submit@debbugs.gnu.org; Fri, 01 Mar 2019 23:51:11 -0500 Received: from lists.gnu.org ([209.51.188.17]:39157) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gzwc2-0005OS-LE for submit@debbugs.gnu.org; Fri, 01 Mar 2019 23:51:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:37576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gzwc1-0006g6-Nn for bug-gnu-emacs@gnu.org; Fri, 01 Mar 2019 23:51:02 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gzwbz-0005L6-Oj for bug-gnu-emacs@gnu.org; Fri, 01 Mar 2019 23:51:01 -0500 Received: from mail-it1-x133.google.com ([2607:f8b0:4864:20::133]:52741) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gzwbv-00059K-MK for bug-gnu-emacs@gnu.org; Fri, 01 Mar 2019 23:50:57 -0500 Received: by mail-it1-x133.google.com with SMTP id g17so81778ita.2 for ; Fri, 01 Mar 2019 20:50:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Cn9SZs7PVg1bQfBgWjbuZBUdzx3b0x1mjw6N6wxglWI=; b=lY+3L3AVxxczGJS+R0CklZujZSv/ShyCO/3upBszjh3+0oboFjIk9FQ/bEvU5U35YF Is0cJ/5EzY3BOaQhkdmTsWVXB4FmUTNulzjcTyoQ8zcFFw0e6sGnFISno79XNr7LTBsg OX79DOGTg8/JWo/iZIR7/e25hLJ0A9X3EQ+OKsnHG6zSMEFne8iYE+lVU0l9JVw4ZClu HKqayE12bbhgEnp4e832E6HSv9wVQYtOoLJoqKlaVLMS6FcG3VmIp9ibRu4FQcIqlsrt JQ72cQp+Lx8u7wRKb6WRpVfhS73oWODYHQqGXN/aD778uyR84uu+KY/ZVAJOXmEAQQ8g ZhMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Cn9SZs7PVg1bQfBgWjbuZBUdzx3b0x1mjw6N6wxglWI=; b=WUWZofpuxjOhvRRz3eHUk9diodfFRZOmgPOy5oikuBwhx9A5P8/o0Eux5M0mqf5NJT N3k2WGLaA/lA2EVpOF9k/Lb/6N5Pvh+2BsqT+ODyNhP4PD0Mb9hxSiWD6WtBBUeNy6Ow 0AUVchyd1n3n8XLPcyPihigZAmpmkiom8FFnKSA0brBtlnjoIKyoRDEgzrrnMzTPFw6A i5qgN37T9H2Ov2DoyxCluCHBWLzCnRI5yUacm9BLKDE+56ta3au1AGyqwRssoQyAy9s0 Xm/M1twe/et5KoFDXMjGQIPN5QpW3ooBbsvyO9Kg9ThhbF3XxC3De5v9eWZv20AfPXj7 2LDA== X-Gm-Message-State: APjAAAUP3VxwQhZscLX5lXj67RiKuIVLyK0YHuNUC+Ik0O2GYTDrMvUo 8ij0M2KjTHoAT7pk+8ya0wc5+aCcY1F8c1dEtKompksO X-Google-Smtp-Source: APXvYqwyFbWiklTEsGZE28/BCf/MAeJrq8Atg11tTvfDNl8zGXN3ttxfDuc5bX/59oeQZNIMtFaSOuhYuXQtf/xYc8o= X-Received: by 2002:a24:4e0f:: with SMTP id r15mr5304081ita.163.1551502236430; Fri, 01 Mar 2019 20:50:36 -0800 (PST) MIME-Version: 1.0 From: "Miguel V. S. Frasson" Date: Sat, 2 Mar 2019 01:50:10 -0300 Message-ID: Subject: alist-get has unclear documentation To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::133 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hi In most recent subr.el (git repository, lisp folder), this is the definition of alist-get: (defun alist-get (key alist &optional default remove testfn) "Return the value associated with KEY in ALIST. If KEY is not found in ALIST, return DEFAULT. Use TESTFN to lookup in the alist if non-nil. Otherwise, use `assq'. This is a generalized variable suitable for use with `setf'. 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." (ignore remove) ;;Silence byte-compiler. (let ((x (if (not testfn) (assq key alist) (assoc key alist testfn)))) (if x (cdr x) default))) * Last paragraph starts with `This'. What is `this'? ALIST? TESTFN? alist-get itself? Since this doc-string is there for a long time, it may be the case it makes sense and I didn't understand it, but again in this case, others will not understand as well, unclear doc-string. * How do I use `this' or `it' to set a value? Function is alist-*get* but somehow I can set values. A simple example on doc-string and/or info node would explain everything. * Action of REMOVE is described, but it doesn't correspond to code. REMOVE is ignored. * Probably Elisp info follows misleading doc-string. Miguel -- Miguel Vinicius Santini Frasson mvsfrasson@gmail.com From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 02 04:25:56 2019 Received: (at 34708) by debbugs.gnu.org; 2 Mar 2019 09:25:56 +0000 Received: from localhost ([127.0.0.1]:56985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h00u4-00040w-8d for submit@debbugs.gnu.org; Sat, 02 Mar 2019 04:25:56 -0500 Received: from mout.web.de ([217.72.192.78]:59217) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h00u2-00040j-5j for 34708@debbugs.gnu.org; Sat, 02 Mar 2019 04:25:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1551518746; bh=2Sjk4kAcDtv7Drdm85e/e4d9LxAV66CmfinX03qroI0=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=knAh1ZxaEeLp0pq2OYk2wq4eIWaAxNj/f4oXCCDqmHZBnN/cyBc7Z1M4MmNr75lbi kC1YygjHeuC5Zx7UTI+m0D6qYMUid10td3JEB6LrWPWiQhqr7pMOuxys2VI2qfPiKG nWBCIZ2MGTZ/XFrwFIabF+HVNfAX/hif/M4HxLbU= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MAMpq-1goUaG3C0I-00BbSu; Sat, 02 Mar 2019 10:25:46 +0100 From: Michael Heerdegen To: "Miguel V. S. Frasson" Subject: Re: bug#34708: alist-get has unclear documentation References: Date: Sat, 02 Mar 2019 10:25:45 +0100 In-Reply-To: (Miguel V. S. Frasson's message of "Sat, 2 Mar 2019 01:50:10 -0300") Message-ID: <87wolhr5k6.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:MSBl9mIOYqP4GvwDZAqSJ2fPOo7PtsW45QxWX7lN2IzYtQB9s48 k7acMA06aWI9oApwDZpcFT0NpY2s30y5RMBVVzMBwZRH9pWIFI6gimvF4d3Ox7ztqD1WM9c YiRLBAFGLu6LdEFbGf6XMDbW8EeOaYmzEvN9+Phoaqz7hccvRZbggDhsSO0zKhSqIEri3gv KRsI6pWKb6djzSibpv6dQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:ooiphD278FA=:NjnyEh1OurJ4zDpOTnjrwV 5vfuCLkcWLhFQtsHYbXQmv1+VMflAcQiKoU7rrZDeoYJtoNBLzXTQ2zlS8sNA8WxlEN7YG9Lk PiXVkq4FZAzfcwDqKNxL6bLh+o7Al0yW3KP/wzurzFjN4nnetfztsHsTaLeSw8UqEKqZcWk93 ZoKTR+tzgTYv7uwNtOA+uKBeFa4n+mlu4PBudTmT3oqhRT9JcDuhRhnvB6wKiKktkc1EOVtW6 FuonpRCDWUno1XSiVu9jwvE6gC5AxrG1dXl5NEivYZrrZIf4WowHFL+5LyNFSjz2v4k9p/5rm 7x0UJUkp3MrgrZmGnLuyBaTjyLyAbdS7zmCIhKFkIk2eATZX4+8i4tQefpfh9LSmC1rtPqLFt QKAEF7vaU41FEyaCNZv0RGPPEUsrPOrH6G6Z0gwM2HbxQQ5kkWfnt+LSCCFnEEse38D7fzaEQ +lVDlDg8CF49efj5lP1oWK6juONCPCsusLZjSfy3WQPKI4/M9UAnduvDtasE1lRPqNpmx5/CD Pl6ImqEUO1V3SL2fl5geG/mJkxPQH7Yoppy3U9KoYcbUaHRx8nIA7xbJtpFqOMfsgqT6/afOy wxfIHR6reYKssUWK55Rk2ZyxLI9gb5L/lKGxbWoJjb3eJC1ropLXah9T/TMGH9Wy8qFfEwclC fqFDPEw1iKx71H1h2eNtTF9s6X6e1mwfgKZYhcUJp1Z1S2IfBxev86vu97lY9QDWgWizUiE+c 6h+qH3/fwv+NfNaLMNvpd9mIhnqI/LEWvvpLvVp1oQVdFoa2pEuQ7tNPmI9bO9sjEOM7BXdIn UROYVQ+9o/l4zYHSVQDiZScOpMV9VJLu95PDklb/6b2Gvf8SdZYW2pW98c5eMjOlT4Tq3HGSJ YgPv3f+4t9JBeeS/NIu5RIqxGVbSIx7bVMwGG+qKtCvsOJRoVTJhILGjiMqaYizLU0Z6PH/d2 FvjbX3yoeWA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) "Miguel V. S. Frasson" writes: > * Last paragraph starts with `This'. What is `this'? ALIST? TESTFN? > alist-get itself? Only one of those makes sense to me. Do you know what a generalized variable is? > * How do I use `this' or `it' to set a value? Function is alist-*get* > but somehow I can set values. A simple example on doc-string and/or > info node would explain everything. That could make sense, since it's an important use case and generalized variables are probably not something everyone is used to. > * Action of REMOVE is described, but it doesn't correspond to code. > REMOVE is ignored. That's ok: the generalized variable is implemented in gv.el. Michael. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 02 10:41:20 2019 Received: (at 34708) by debbugs.gnu.org; 2 Mar 2019 15:41:20 +0000 Received: from localhost ([127.0.0.1]:57832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h06lL-0004h6-PN for submit@debbugs.gnu.org; Sat, 02 Mar 2019 10:41:20 -0500 Received: from mail-it1-f176.google.com ([209.85.166.176]:35704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h06lK-0004gs-CJ for 34708@debbugs.gnu.org; Sat, 02 Mar 2019 10:41:19 -0500 Received: by mail-it1-f176.google.com with SMTP id 188so1436546itb.0 for <34708@debbugs.gnu.org>; Sat, 02 Mar 2019 07:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7R5YoNz3mebPcbPEmVw4v6sr3hIOoNo8UPgzdvuIMig=; b=RqdjM7IkbTyJDREP88WsVtdLIJ6mK/OT9Z4nM0/WCkH/tfDqzATorDsjhAYC91pXhp zQSiLJYBMQP3YxJtj5cqfNkK0jMzPO0hQ+SnKMTcZpGaqS8joCMhV07J42ZH+9m5bVTe gWSxDxmCPpn9t0chNuu0oMIxC+BPNlV5sZX5YSr9TCuAtSJLt+Pq099zyf+/USreeAQn kJM2UAINeqT4TYMm+c2GqAO5vhyPizWCTbfYvaOH0CPgrx3dVZJH5Af7q4WnRY4Xntrd z0q+SNx4mRpbYAkB4jtYQiYrdutN3+FJuGmw4v5pnzqkol4zT7XpCIiztVoCFBPHs1ia f1wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7R5YoNz3mebPcbPEmVw4v6sr3hIOoNo8UPgzdvuIMig=; b=ihQUamupVulyKIL5rk389UYxL+UiyuQLVfv/OVNChb3iYl9Q3Jt9nHEqcw5X5m9/bP coftiOtP3fee3J6YkguACmJCFy9vnUtXZXL1ZrGXd9oJmgJ3ZyMFsa2eHxGbc7G3kqAc A9Qs+kRaqPA1PRt0Kvxfba1HJNSAbL23+mOyUrogI8TT4JrLss7CQRnGWU6wfT6TjTcO 1pycSkJIxG7JGB9gyghcibfM/GMaEzCvLXzNvRlhoXD3NLEoPWK+AM8tH30VAP5j7dCM T4YEr1evD5ouiYaQfeJ0zUpTVBoTckIdz47qq7dknxtWYObf+FX6QEwS9YX7HbIhNHDY DIYw== X-Gm-Message-State: AHQUAuaGONHFoI9caZVCfrXETXPbo5xGolYEfqWx86cF3Fy5prkvjWD0 vDlj+ZdwmNS1eo1D/fvMAQdWRxV+ghCnXV0f9PI= X-Google-Smtp-Source: AHgI3IZEoHdAtLfE7OBXrE8cgzeHA904BSLbY4Boc/tSnUadgWVSuNmkDbrHFjDte4Ts1XSrs7DHL+e1QYkF/Qa3ovM= X-Received: by 2002:a24:ac58:: with SMTP id m24mr6059209iti.129.1551541271313; Sat, 02 Mar 2019 07:41:11 -0800 (PST) MIME-Version: 1.0 References: <87wolhr5k6.fsf@web.de> In-Reply-To: <87wolhr5k6.fsf@web.de> From: "Miguel V. S. Frasson" Date: Sat, 2 Mar 2019 12:40:57 -0300 Message-ID: Subject: Re: bug#34708: alist-get has unclear documentation To: Michael Heerdegen Content-Type: multipart/alternative; boundary="00000000000054c54e05831e5a84" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34708 Cc: 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000054c54e05831e5a84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michael Em s=C3=A1b, 2 de mar de 2019 06:25, Michael Heerdegen escreveu: > "Miguel V. S. Frasson" writes: > > > * Last paragraph starts with `This'. What is `this'? ALIST? TESTFN? > > alist-get itself? > > Only one of those makes sense to me. Do you know what a generalized > variable is? > I think so, ALIST, but 'this' should be the last thing that was referred to or talked about. The point is that the documentation must be clear, and it is not in this case. I know about generalized variables but really never used myself. > * How do I use `this' or `it' to set a value? Function is alist-*get* > > but somehow I can set values. A simple example on doc-string and/or > > info node would explain everything. > > That could make sense, since it's an important use case and generalized > variables are probably not something everyone is used to. > I can't imagine how to *set* anything with alist-get. It seams to me that it just use the value of ALIST for look up, so talk about generalized variables is meaningless to me here. > * Action of REMOVE is described, but it doesn't correspond to code. > > REMOVE is ignored. > > That's ok: the generalized variable is implemented in gv.el. > > > Michael. > Miguel > --00000000000054c54e05831e5a84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael=C2=A0

<= div dir=3D"ltr" class=3D"gmail_attr">Em s=C3=A1b, 2 de mar de 2019 06:25, M= ichael Heerdegen <michael_he= erdegen@web.de> escreveu:
&q= uot;Miguel V. S. Frasson" <mvsfrasson@gmail.com> writes:
> * Last paragraph starts with `This'. What is `this'? ALIST? TE= STFN?
> alist-get itself?

Only one of those makes sense to me.=C2=A0 Do you know what a generalized variable is?

I think so, ALIST, but 'this'= should be the last thing that was referred to or talked about. The point i= s that the documentation must be clear, and it is not in this case.=C2=A0

I know about generalized = variables but really never used myself.

> * How do I use `this' or `it' to set a value? Function is alis= t-*get*
> but somehow I can set values. A simple example on doc-string and/or > info node would explain everything.

That could make sense, since it's an important use case and generalized=
variables are probably not something everyone is used to.
<= /div>

I can't imagin= e how to *set* anything with alist-get. It seams to me that it just use the= value of ALIST for look up, so talk about generalized variables is meaning= less to me here.

> * Action of REMOVE = is described, but it doesn't correspond to code.
> REMOVE is ignored.

That's ok: the generalized variable is implemented in gv.el.


Michael.

Miguel=C2=A0
--00000000000054c54e05831e5a84-- From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 02 13:11:05 2019 Received: (at 34708) by debbugs.gnu.org; 2 Mar 2019 18:11:05 +0000 Received: from localhost ([127.0.0.1]:57850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h096H-0008GP-Gp for submit@debbugs.gnu.org; Sat, 02 Mar 2019 13:11:05 -0500 Received: from mout.web.de ([212.227.17.12]:39723) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h096F-0008Ft-Eu for 34708@debbugs.gnu.org; Sat, 02 Mar 2019 13:11:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1551550256; bh=GQRBN5xXtSKLGEibKoOzTAjlhxR7SwdJgLSlhqa7614=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=PcpNAm4zQZPDOKIu87Rs4LB/JQGiHmnGrGiZE5h/OM8y/R8Lkklkp8BTj0yvyy36Z y0kOqmWHY/FVThSar3eMzeEvyO5CweBgHMqHOe5+5tzQRxoBbcpesDOzyzuWs9X0UX xhFjKzHy8kcCmnkTYZFk+CnDzV6c7vkl4eLGGDK4= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0M4ZXs-1hC3qO173E-00yhyk; Sat, 02 Mar 2019 19:10:56 +0100 From: Michael Heerdegen To: "Miguel V. S. Frasson" Subject: Re: bug#34708: alist-get has unclear documentation References: <87wolhr5k6.fsf@web.de> Date: Sat, 02 Mar 2019 19:10:55 +0100 In-Reply-To: (Miguel V. S. Frasson's message of "Sat, 2 Mar 2019 12:40:57 -0300") Message-ID: <87y35xdu4w.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:Mds/o52vF/mrGdu4OO3stGG3fhEztKCLr88Ijr3qF+ip5MG44oA Flxyh5u5t/BuJDVjAfNUG3GOmLchlPxYsc8hK4FbXtUGkZuSYGAylbFgCQh1olJotoOpxGL orXV1v9Qd+ABF/GIUi82E115TRMZhvjouvMBLLx04Gz30ZuZE3U8zCkmtnNGOT/d91SddKs A7n8qTQYCYyRR8MMidhFw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:fziJvnnVotA=:PuUm4untnrNf6JhCVjEmV6 /e9a5ZUVwpjFJRGtZB2hJYpnpCqzyMSghxJKlnibTtKeyZkPaNpWYNFnVvwn4kiCXquz8KrSt eIvw/uzdwbSkWZaafxcWn4v2Mf9X4O4lOHoVM01hW8gVocVluiQau91P8GDfQ4PbER+7T/A6P KZ29iwUbLfvo8Z1tWolO1HkcZYz+G7ykDJZWa/Le5Q73nXCACTKPl9N0gHlgmQXatYxyIFm2S /x/Mr7SujOg6FjIK6b8DlXnhHO43emGLaxIuzCt4wyLxpi9o9KF8K9Jv5zoS5AWtVwkaagcwL 0AmFJSCtNupX7/XmzjfdBfkcDTO9KkFsqkOK+LxD+Yk0FoNDdf2P+Navla5n3g8burnmz0uU+ 10VZaJR8ZgIXaDicFEpKfYYf7cEr5HcjIeRKmJnZD6V2/w/nkIVIvWjoJVHT8LhNh+UBniyam HqT7+uWvT2ho2mpZ6RmgxXbfvmmxqlkhWAN7zI7jn/Xo1QT7FgP0/1FP8AFTapKuTeCIVBH6Z 9Jg+uKfH4t+yjjaUBCjzvOilvdi7Fr/h7/mKlRS+qrcUv6qNT1VxNZ9pKKaJMh1VpFuN5eQOR EvJp/Yd5Vn4k5lHN7wl1ZE6lCENiKihJ+2bRkmGR3//lHS8mP7783vUEJ52KbA+9EcSbO2ani eU5jDrUtXfYKdFOcrmQGNtkG+KDBJOdNHQm3T1F1BErOrl3UVxZ6dQV0JY8gP6fDLJmVVCqG9 YYDR9XJRF2uUtMXE0ukLgSPAs+omLF2Q5sS9I4vdjVhp4439IVf2vBXbCX7x7rwxEaX93HrNC T8fWXAgXMlOFP9RMn+tdTbJbR5d281RbcusBZbUhiu86VbDVHbdQek8qy4ykWgJru/jg2fuxL FUkjyT7M3zwMRnqJWWKIL9vvXpCF39RDfY5B5hMS8hlik0DyRfEgNfGdgns39mkC/NPHooKmL NV9po79j9+w== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) "Miguel V. S. Frasson" writes: > I can't imagine how to *set* anything with alist-get. It seams to me > that it just use the value of ALIST for look up, so talk about > generalized variables is meaningless to me here. You use it like this: say variable V is bound to an alist, then you can do (setf (alist-get key V) value). After that, (alist-get key V) will evaluate to VALUE, so you have "set" that place. In the general case, V can also be a generalized variable, e.g. (car SOMETHING-ELSE). To replace the word "this" with something better is not so easy. We could write "The name of this function can be used to build expressions that can be used as a generalized variable", but I doubt it will make things clearer for somebody not familiar with the concept of generalized variables. Using this function name to build place expressions is not different from using other function names that allow to be used for generalized variables. I would rather go with an example, which I think is justified because using this function name in place expressions is the canonical way to modify alists and people need to use it (there is no `alist-put') no matter if they are familiar with generalized variables. Michael. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 02 14:07:01 2019 Received: (at submit) by debbugs.gnu.org; 2 Mar 2019 19:07:02 +0000 Received: from localhost ([127.0.0.1]:57861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h09yN-00019O-41 for submit@debbugs.gnu.org; Sat, 02 Mar 2019 14:07:01 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44477) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h09yK-00019A-Fb for submit@debbugs.gnu.org; Sat, 02 Mar 2019 14:06:56 -0500 Received: from lists.gnu.org ([209.51.188.17]:53924) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h09yF-00086r-DP for submit@debbugs.gnu.org; Sat, 02 Mar 2019 14:06:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h09yE-0001U2-EN for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 14:06:51 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50,RDNS_NONE autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h09yD-000855-Ln for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 14:06:50 -0500 Received: from [195.159.176.226] (port=46370 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h09yD-00081e-E1 for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 14:06:49 -0500 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1h09yB-00118R-AB for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 20:06:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Eric Abrahamsen Subject: Re: bug#34708: alist-get has unclear documentation Date: Sat, 02 Mar 2019 11:06:39 -0800 Message-ID: <87wolhhz9c.fsf@ericabrahamsen.net> References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cancel-Lock: sha1:FsLgoyvLKOWv0DH2HMOQ9fIA5ms= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Michael Heerdegen writes: > "Miguel V. S. Frasson" writes: > >> I can't imagine how to *set* anything with alist-get. It seams to me >> that it just use the value of ALIST for look up, so talk about >> generalized variables is meaningless to me here. > > You use it like this: say variable V is bound to an alist, then you can > do (setf (alist-get key V) value). After that, (alist-get key V) will > evaluate to VALUE, so you have "set" that place. In the general case, V > can also be a generalized variable, e.g. (car SOMETHING-ELSE). > > To replace the word "this" with something better is not so easy. We > could write "The name of this function can be used to build expressions > that can be used as a generalized variable", but I doubt it will make > things clearer for somebody not familiar with the concept of generalized > variables. Using this function name to build place expressions is not > different from using other function names that allow to be used for > generalized variables. One other phrase you often see here is "setf-able place". I don't know if that's formally acceptable in docstrings, but it would be much more comprehensible to say "this form is a setf-able place", and would give the key hint (setf) as well. It's true it's pretty weird to refer to a function call as a variable. > I would rather go with an example, which I think is justified because > using this function name in place expressions is the canonical way to > modify alists and people need to use it (there is no `alist-put') no > matter if they are familiar with generalized variables. Most definitely, this needs examples. I also agree that the REMOVE usage needs an example -- I made it work eventually, but it took a fair bit of experimentation. Eric From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 02 14:51:43 2019 Received: (at 34708) by debbugs.gnu.org; 2 Mar 2019 19:51:44 +0000 Received: from localhost ([127.0.0.1]:57884 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0Aff-0002AB-G9 for submit@debbugs.gnu.org; Sat, 02 Mar 2019 14:51:43 -0500 Received: from mail-it1-f170.google.com ([209.85.166.170]:40302) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0Afd-00029y-4J for 34708@debbugs.gnu.org; Sat, 02 Mar 2019 14:51:41 -0500 Received: by mail-it1-f170.google.com with SMTP id l139so2001615ita.5 for <34708@debbugs.gnu.org>; Sat, 02 Mar 2019 11:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=txksbu9bNDcuIsx0VgCYZN69FcvrvgRJYK6x4VNpxzc=; b=H6eoqtJTLmHx2unu7ctT88VFPd+QXlb7RfNvrdjdv4edQLav8mbIjiJAeFIjaXi/gl dWT32fc383ZtfZNm+GY9bwO1Na4QYG+RUac1vWPJpooqlmzK8J+3275jk4beuTGAaSRw 0aSS1jFNABDKHk0XcgrRfOOUalBkCsrKQPbef9eO6idB36ocTyvuFl7CIM8PSiMVS8z4 56LJVR1DJOXpdaCwlfDYCjEWZ7BWMjtAa/tjNA0+plIUo17jF/UUQeo3bHq4E5LmgByJ 1kcDVTfS3VnePuZYpMd5MC2jd7UTAaFDGGBPwDhTIWQKV3vAdVRuYalJsP7gznay2DKZ J0Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=txksbu9bNDcuIsx0VgCYZN69FcvrvgRJYK6x4VNpxzc=; b=i6VBMnt4CeXfflaSuR2b0oRX9g+Zo34KR1O+zRM54nuBpUhOYW0VDQ6iYYBLveQtS9 w3X6je8vcLGXxKGBF7aj2Q1cuSOVht6jLJQdBZqZV8fV+c6rMCALwy8GdsghhnpW7Wr0 WIiWy/7DEfCzGhKVLcH79QBVa8fjYrXyjH+1d4sljBo0HeEcg1S6/x8Jfoibxi9RtjR3 Kxf+qeQkur4md+51CDl0T50IUGhbSC3JDjzhqeOjFymZvj16NbuZ5Ku++ZCby2+fjD1W jgXATr3M6GJDzyESYn/L1sNzUHuDTUBgtYCE5iz/zBVTqujZHZ9053FLqb43xJ6Di2Px 3Zxg== X-Gm-Message-State: APjAAAWL/tCUjRfZKFFLkiPuke3nb3Mms4VIUVy+sRC489TwppN3sN2v BXzCvx1OK9IvDNXfigH6S0jxsJTGG3e9sYOxj0o= X-Google-Smtp-Source: APXvYqw/6LRY1/01ah0uPZ+BoH6KP075Vv7FkesjSyb59m0MsnQz4LpPx2PkMURdRKBUdCooY9wSbF0b2P7qm02IMIM= X-Received: by 2002:a24:4e0f:: with SMTP id r15mr6831734ita.163.1551556295130; Sat, 02 Mar 2019 11:51:35 -0800 (PST) MIME-Version: 1.0 References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> In-Reply-To: <87y35xdu4w.fsf@web.de> From: "Miguel V. S. Frasson" Date: Sat, 2 Mar 2019 16:51:25 -0300 Message-ID: Subject: Re: bug#34708: alist-get has unclear documentation To: Michael Heerdegen Content-Type: multipart/alternative; boundary="000000000000d2044c058321d94e" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34708 Cc: 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000d2044c058321d94e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thanks for the explanation. Now it is clear. I use alists a lot. I will use it better. Miguel Em s=C3=A1b, 2 de mar de 2019 15:10, Michael Heerdegen escreveu: > "Miguel V. S. Frasson" writes: > > > I can't imagine how to *set* anything with alist-get. It seams to me > > that it just use the value of ALIST for look up, so talk about > > generalized variables is meaningless to me here. > > You use it like this: say variable V is bound to an alist, then you can > do (setf (alist-get key V) value). After that, (alist-get key V) will > evaluate to VALUE, so you have "set" that place. In the general case, V > can also be a generalized variable, e.g. (car SOMETHING-ELSE). > > To replace the word "this" with something better is not so easy. We > could write "The name of this function can be used to build expressions > that can be used as a generalized variable", but I doubt it will make > things clearer for somebody not familiar with the concept of generalized > variables. Using this function name to build place expressions is not > different from using other function names that allow to be used for > generalized variables. > > I would rather go with an example, which I think is justified because > using this function name in place expressions is the canonical way to > modify alists and people need to use it (there is no `alist-put') no > matter if they are familiar with generalized variables. > > Michael. > > > --000000000000d2044c058321d94e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

Thanks for the explanation. Now it is clear. I use alists a = lot. I will use it better.=C2=A0

Miguel=C2=A0

<= br>



=
Em s=C3=A1= b, 2 de mar de 2019 15:10, Michael Heerdegen <michael_heerdegen@we= b.de> escreveu:
"Miguel= V. S. Frasson" <mvsfrasson@gmail.com> writes:<= br>
> I can't imagine how to *set* anything with alist-get. It seams to = me
> that it just use the value of ALIST for look up, so talk about
> generalized variables is meaningless to me here.

You use it like this: say variable V is bound to an alist, then you can
do (setf (alist-get key V) value).=C2=A0 After that, (alist-get key V) will=
evaluate to VALUE, so you have "set" that place.=C2=A0 In the gen= eral case, V
can also be a generalized variable, e.g. (car SOMETHING-ELSE).

To replace the word "this" with something better is not so easy.= =C2=A0 We
could write "The name of this function can be used to build expression= s
that can be used as a generalized variable", but I doubt it will make<= br> things clearer for somebody not familiar with the concept of generalized variables.=C2=A0 Using this function name to build place expressions is not=
different from using other function names that allow to be used for
generalized variables.

I would rather go with an example, which I think is justified because
using this function name in place expressions is the canonical way to
modify alists and people need to use it (there is no `alist-put') no matter if they are familiar with generalized variables.

Michael.


--000000000000d2044c058321d94e-- From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 02 15:45:55 2019 Received: (at submit) by debbugs.gnu.org; 2 Mar 2019 20:45:55 +0000 Received: from localhost ([127.0.0.1]:57902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0BW7-0003NN-Im for submit@debbugs.gnu.org; Sat, 02 Mar 2019 15:45:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0BW5-0003NA-Qb for submit@debbugs.gnu.org; Sat, 02 Mar 2019 15:45:54 -0500 Received: from lists.gnu.org ([209.51.188.17]:57132) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h0BW0-0006NZ-Kq for submit@debbugs.gnu.org; Sat, 02 Mar 2019 15:45:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0BVz-00041b-PO for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 15:45:48 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_40,RDNS_NONE autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h0BIp-0004zd-Ph for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 15:32:12 -0500 Received: from [195.159.176.226] (port=36178 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h0BIp-0004yZ-Hx for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 15:32:11 -0500 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1h0BIn-000SoK-Te for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 21:32:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Eric Abrahamsen Subject: Re: bug#34708: alist-get has unclear documentation Date: Sat, 02 Mar 2019 12:32:01 -0800 Message-ID: <87d0n9hvb2.fsf@ericabrahamsen.net> References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cancel-Lock: sha1:+ArFu6g19NIyMx25W8ohh/lO2fY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Miguel V. S. Frasson" writes: > Hi > > Thanks for the explanation. Now it is clear. I use alists a lot. I will use > it better. This function is so handy I've pretty much stopped using plists at all. This one does everything you need. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 02 19:15:48 2019 Received: (at 34708) by debbugs.gnu.org; 3 Mar 2019 00:15:48 +0000 Received: from localhost ([127.0.0.1]:57964 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0EnD-0008F5-RX for submit@debbugs.gnu.org; Sat, 02 Mar 2019 19:15:48 -0500 Received: from smtp-4.orcon.net.nz ([60.234.4.59]:40229) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0EnB-0008Ew-BV for 34708@debbugs.gnu.org; Sat, 02 Mar 2019 19:15:46 -0500 Received: from [150.107.172.103] (port=5185 helo=[192.168.20.103]) by smtp-4.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1h0En4-0003ts-1D; Sun, 03 Mar 2019 13:15:38 +1300 Subject: Re: bug#34708: alist-get has unclear documentation To: Eric Abrahamsen , 34708@debbugs.gnu.org References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> <87wolhhz9c.fsf@ericabrahamsen.net> From: Phil Sainty Message-ID: Date: Sun, 3 Mar 2019 13:15:37 +1300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <87wolhhz9c.fsf@ericabrahamsen.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 3/03/19 8:06 AM, Eric Abrahamsen wrote: > Most definitely, this needs examples. I also agree that the REMOVE > usage needs an example -- I made it work eventually, but it took a > fair bit of experimentation. Agreed. I think the remove syntax is all but unreadable: (setf (alist-get KEY LIST t t) t) to remove items from LIST with key eq to KEY. Unless accompanied by comments, I do not think that meaning obvious at all. This variant gives a better idea... (setf (alist-get KEY LIST :remove :remove) :remove) I struggle to imagine a scenario where I wouldn't use some more explicit syntax for deletion, though; even when the decision to remove or not is being arrived at dynamically. -Phil From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 03 06:33:07 2019 Received: (at 34708) by debbugs.gnu.org; 3 Mar 2019 11:33:07 +0000 Received: from localhost ([127.0.0.1]:58105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0PMg-0001HW-Nm for submit@debbugs.gnu.org; Sun, 03 Mar 2019 06:33:07 -0500 Received: from mail-it1-f178.google.com ([209.85.166.178]:38814) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0PMe-0001H2-8N for 34708@debbugs.gnu.org; Sun, 03 Mar 2019 06:33:04 -0500 Received: by mail-it1-f178.google.com with SMTP id l66so3508040itg.3 for <34708@debbugs.gnu.org>; Sun, 03 Mar 2019 03:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ml9NS7sFeEnhWwU5qEpw/NTSpjKEi8p/F94GtrGDg2Q=; b=eXzK1MU6pDiTzThfDv5wMzSgQpvKGNfefnTDz8kV0zd9BXX+tDJun2RIQsPyASQWYr 20K5KssdBdyFHey/tf0jxQaIHIpFsi5WZ95/GuxnXy5u8iOl6rFx0v7uGKjUFMJsOqTN oz33whlXiZahWQ8gqd8hxVDcqYNhwtNaITUd5n17jspHDRKqmOc0CY4N4N4EE6jzG4n1 2kacXTFnXc2s/ULojdd/qa2h7RpcIE9D4s9NwcTocHjxBS8VJLxCIrrKTYx36PhglrY/ aA3Kisf3B6YcJ7t/d7Cls+V5dsdJ1bVOGW3aRavVFfYF6YNVLO51ONZSUTEYFVeQvusz Mp9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ml9NS7sFeEnhWwU5qEpw/NTSpjKEi8p/F94GtrGDg2Q=; b=P1YmL9MEfz62PVp2o6VDMj8JaCur5AWcZh4F0swDwUxEwoRXlxgaKjPL0P/2zQLzpv z7/GHg2NMZIbT1BZq/TBl5G+2rS5+2iSfunqmKJE5QfcP0GbTz4KnbCIWVfGaWztSqQl 7C76rzLSw97217jV3PBXB8b3yPYj8eodtiYMawV0jLohd/yTRQHGPSrs0cDF/i5xBGID hDSAGIN3/oG+kahk0aQvdm17z2OFHuS6etD+gqdsxPNpAqQBFDGrejYFP+wQDWTmy/Fn xKqb+Ibc/lBcqeGEnrFpqrbaIE4XtV0lNkIIe/KSduxEtjoIGZLyi2QgTTwo845iFnBk j1uw== X-Gm-Message-State: APjAAAU2rP6weddYriwT8pRJSxgWSZrjHEOOeu0I+8v+2fF5eAWUjGxM ENMudvsZwjHURuf9un/pCH9OROogdJm/DlWWbLI= X-Google-Smtp-Source: APXvYqxXmsvccw6GKo8Gn+hA27rDyBHiuZpVt6pamHh39nH34mdj/1KX3nXavG8K3+OvPjM8I3JAi75hOWPZ3/W/wfc= X-Received: by 2002:a24:4e0f:: with SMTP id r15mr8054740ita.163.1551612778364; Sun, 03 Mar 2019 03:32:58 -0800 (PST) MIME-Version: 1.0 References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> In-Reply-To: <87y35xdu4w.fsf@web.de> From: "Miguel V. S. Frasson" Date: Sun, 3 Mar 2019 08:32:45 -0300 Message-ID: Subject: Re: bug#34708: alist-get has unclear documentation To: Michael Heerdegen Content-Type: multipart/alternative; boundary="0000000000007bc5ea05832f0028" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34708 Cc: 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000007bc5ea05832f0028 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi I think the sentence below is a good and short explanation for the doc-string. The return value can be conveniently used as a generalized variable (a place) to set the value associated with KEY in ALIST, like in the example (setf (alist-get key alist) new-value) Miguel Em s=C3=A1b, 2 de mar de 2019 15:10, Michael Heerdegen escreveu: > "Miguel V. S. Frasson" writes: > > > I can't imagine how to *set* anything with alist-get. It seams to me > > that it just use the value of ALIST for look up, so talk about > > generalized variables is meaningless to me here. > > You use it like this: say variable V is bound to an alist, then you can > do (setf (alist-get key V) value). After that, (alist-get key V) will > evaluate to VALUE, so you have "set" that place. In the general case, V > can also be a generalized variable, e.g. (car SOMETHING-ELSE). > > To replace the word "this" with something better is not so easy. We > could write "The name of this function can be used to build expressions > that can be used as a generalized variable", but I doubt it will make > things clearer for somebody not familiar with the concept of generalized > variables. Using this function name to build place expressions is not > different from using other function names that allow to be used for > generalized variables. > > I would rather go with an example, which I think is justified because > using this function name in place expressions is the canonical way to > modify alists and people need to use it (there is no `alist-put') no > matter if they are familiar with generalized variables. > > Michael. > > > --0000000000007bc5ea05832f0028 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

I think t= he sentence below is a good and short explanation for the doc-string.
=

The return value can be conve= niently used as a generalized variable (a place) to set the value associate= d with KEY in ALIST, like in the example
=C2=A0(setf (alis= t-get key alist) new-value)

Miguel=C2=A0


Em s=C3=A1b, 2 de m= ar de 2019 15:10, Michael Heerdegen <michael_heerdegen@web.de> escreveu:
"Miguel V. S. Frasson" <mvsfrasson@gmail.co= m> writes:

> I can't imagine how to *set* anything with alist-get. It seams to = me
> that it just use the value of ALIST for look up, so talk about
> generalized variables is meaningless to me here.

You use it like this: say variable V is bound to an alist, then you can
do (setf (alist-get key V) value).=C2=A0 After that, (alist-get key V) will=
evaluate to VALUE, so you have "set" that place.=C2=A0 In the gen= eral case, V
can also be a generalized variable, e.g. (car SOMETHING-ELSE).

To replace the word "this" with something better is not so easy.= =C2=A0 We
could write "The name of this function can be used to build expression= s
that can be used as a generalized variable", but I doubt it will make<= br> things clearer for somebody not familiar with the concept of generalized variables.=C2=A0 Using this function name to build place expressions is not=
different from using other function names that allow to be used for
generalized variables.

I would rather go with an example, which I think is justified because
using this function name in place expressions is the canonical way to
modify alists and people need to use it (there is no `alist-put') no matter if they are familiar with generalized variables.

Michael.


--0000000000007bc5ea05832f0028-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 03 07:21:59 2019 Received: (at 34708) by debbugs.gnu.org; 3 Mar 2019 12:21:59 +0000 Received: from localhost ([127.0.0.1]:58122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0Q7z-0002V4-1A for submit@debbugs.gnu.org; Sun, 03 Mar 2019 07:21:59 -0500 Received: from mout.web.de ([212.227.15.4]:35811) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0Q7x-0002Ur-Jh for 34708@debbugs.gnu.org; Sun, 03 Mar 2019 07:21:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1551615702; bh=58P5pK4iWTvsvkYRft/Yna5FM+sY1oif24C/8dKyafE=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=It5cosyvWbL3JRk5m9DnJ0YErFa9iC8adbuVys3cRdtUcz3BL1gzbjjZB6PUWUY9F FK4dkPUR1UXquFI4+PEcr/rM8blM1APm7gVC6Nc7/MuuoGC77MmjLUnDSzv2MeP8nf 8eyGD6FLlj10+Hw7p478Nvlo18iFs4AbfsJr+8I8= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb001 [213.165.67.108]) with ESMTPSA (Nemesis) id 0MCZP8-1gr6Sy1dpq-009PjC; Sun, 03 Mar 2019 13:21:42 +0100 From: Michael Heerdegen To: "Miguel V. S. Frasson" Subject: Re: bug#34708: alist-get has unclear documentation References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> Date: Sun, 03 Mar 2019 13:21:40 +0100 In-Reply-To: (Miguel V. S. Frasson's message of "Sun, 3 Mar 2019 08:32:45 -0300") Message-ID: <87mumcdu7f.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:b6Nt2l1ABxDwxcEI3rPZZH7a2KmBsthP+rAPwdxfRC09/SnSa13 +BHdjtVvljvqhyVXu5wGWvfks1IC28e29ZXVZsHwsJsuXVlRuR3sbz/eFOpil4tQE+LcyvC VC2RpyyGYG5QpReLgFhGuKr831r0js/df07wS4TGQnql4wHrycc55FA5wZXTRt1mn1nH44p 6u+WLF3QSciy+ZX8VJZHg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:IfjVUPXUjLs=:3gG/yGjYWq2izW9bhlziG7 vdlvQs7EeC8Fi7csR9h0SmWTd0A7B285lBVE2beA3jzMYRb4hukvLaTKDBp7T3wxTIF3ifYA1 H4WU/VkVsEWubaVG0rjUzaBR4dwoOwIDTeIAObxkdm7zRf0Sn8GQeiblWqwP5lXk9x676jauM /IO4xdjacYsF9LzdMFN2Yxhmf9l8ZYt+adpEWFZQmumHWWpTruGkk50iBhJJYcqr0ZX3vldRy KrpT2mkThq0E7qWaIzSRqb1pUUjM1X46rx9O4YOGh54iu6MFI+eM8AkyRre1EN1sqCeGQ0dXU P6MVkB2ZDBbNluaF/5NL0UI8XQPzr9CdcM8qLJRTsOOV9eM0hVZrLFd0/ZD7JleBxs9/WYCQF emO2QPzW4nozocq8KYv8oeeZXLy+av0YAbZ+3v16QjMmGruwKw2KoufFbKaVAvTxIMsMkmvf8 5u7ubJkYXYlyMzdUCgMTTngxN+fNyfKT8yhuZc2H+3nqUK6wChUk1dWXblO7NszXvpz446I+4 hctVtRG6YQoOw6YWK7dvJYRRs+2b/HsUgyeDp1IVGQ3qZgNEeYcVO1VPBX4brpaVJEgdHNK8k sHb7il7jaN3Lwk8Dm8pTER439SFjDbFqN/KPUtTM9Jz7LxaT1ZHFdA3zd9THS7wdGt552vjF1 y6yTtUrXxh0lJvsVRNz9SRifo975v6rLoYidJbtmxezqpgw0lzdpQB+ljlzrtiVjk7Nfciw1z GPcwNKv3w8poOqnywt4q9Mm0iwQ08WmZc0adSSsyB9zcHn8c1b4ORa03rcXSs5gcekPLzDYew cqCpxWgGU+Xt7/VeCJ+BkXwa79HG6ZJnl6FY8kZyBFBAFvyTxNXdOgJQ/x6Mrj2r6sB5xB3zO tiqVXf7vwp7KIInI31LR/KsRc+OIVaSlQy5zygICjb/HCHopshdjSlKxuHKFtYzBVXD9WrHk/ kDy87Ij/jdA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) "Miguel V. S. Frasson" writes: > Hi > > I think the sentence below is a good and short explanation for the > doc-string. > > The return value can be conveniently used as a generalized variable (a > place) to set the value associated with KEY in ALIST, like in the > example (setf (alist-get key alist) new-value) Thanks for the idea. I don't think we should explain it like this however, because when evaluating (setf (alist-get key alist) new-value) the function `alist-get' is never called, so there is no return value. Of course what is sexy about place expressions is that it looks like you would directly set the result of a function call, but what happens is that setf doesn't evaluate the call but analyses it and builds and evaluates code that leads to this result. Eric suggested to say "this form is a setf-able place" but this also doesn't answer the question what this (form) is. `alist-get' is not a form, it's the name of a function. In my opinion it would be cleaner to say something like "the name of this function can be used to build place expressions" or "can be used in place expressions" or so. Better ideas welcome. Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 03 07:51:10 2019 Received: (at 34708) by debbugs.gnu.org; 3 Mar 2019 12:51:10 +0000 Received: from localhost ([127.0.0.1]:58139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0QaD-0005FW-KI for submit@debbugs.gnu.org; Sun, 03 Mar 2019 07:51:10 -0500 Received: from mout.web.de ([212.227.15.4]:49683) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0QaB-0005F4-Cd for 34708@debbugs.gnu.org; Sun, 03 Mar 2019 07:51:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1551617452; bh=mUh6lyY8UAlq9u6U21hkW3NLhMVvureBUIngSrWo+c8=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=lpN9uO7yx1LB5KgmW5E2KRSQqbZpR3Hq0kzIr3/8PzeJ2DuZDjKE9e7pdv/tMOGnc 7KvCaPaNsJI4rDJ+j+Yzxo1cx/jFd7yKqSYW2Kxkuq3VJO0oKyy4TE5u3Yhrwlliuf iTlq1/q9Yj7u/AzesY0gzGpaLVDJ4IMgw+9vnNYQ= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb003 [213.165.67.108]) with ESMTPSA (Nemesis) id 0MLgTT-1gzbV10EaJ-000vLB; Sun, 03 Mar 2019 13:50:52 +0100 From: Michael Heerdegen To: Phil Sainty Subject: Re: bug#34708: alist-get has unclear documentation References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> <87wolhhz9c.fsf@ericabrahamsen.net> Date: Sun, 03 Mar 2019 13:50:51 +0100 In-Reply-To: (Phil Sainty's message of "Sun, 3 Mar 2019 13:15:37 +1300") Message-ID: <87h8ckdsus.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:fSPYFsy5kKUlTQ6uS/nd0p/m6n1yk3LOS/vvKmtpXm/t/RTkI0P s8T+7J5Xvh2+XkxXLhvJh6SAuoC4fOblWNQ/HSQLyahQvY6+Z48DEHk8aTZqlAen7l7jlB4 I8e+K21OgnDrKG3k6RcMbrLWJrbceUe7sl5s+8ojDsxgQ1sRYMuadnTLPl7Inna2iC+4xd/ hGdLWCz5uZK1InAIs7EUQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:ntLkqABjthg=:D1pEazqLvBTR3xUFWa0Vvo JPBOJvgMoGPnjhATRxpGKYjTWZmUnnsH062R4JsYzultIDITNpDca9XSd/xwxIPyOEnvc8Z5n Y+48hiyzkswKPO3LhMhw9uGDBRx7RSqB9+qdw3UjCmCG5jnlz3NyKvM0dlOSlFKLsPtohS7cp qDajofAfDnHdzt+TFxx1EShynTg7tDNU0fZ059vZqZpf6D/QlAqqM1NoqD4rGheNOSM6UeJaA wCmzFp+0+O8xtjV1WjnhFYKS5J/BV8y6toeSjEMsxhKQBYr7vbwwo01wBSdHgshqbG462SNKS zltv82EVg4PCahYKR0KFrfp4nDaoyUuBMM1m26ReRAMToyzMn8R41Va9L/KrF/Xdm2fTtEWd7 5lw/6EQte3Vtce1eB6BvX5vPdlavO/1QMSt4u3BDWS47HfTEPkqOoIPBJ0oILjT04MvNk34Kv 8PUPnUn8Ocxpc+/DbpmUThkSRY87OHhM2LlLy1hyPbHSIQnpmv4V3tjQZppHFrSy5M5lcfM+I UtWmICW5B+BJu/oU4yI5CoZry3KCNSmjXAI6qEWaBEKqbZusRhDCfhj9f1c63U8ohOsXWkcxa 9PagXj0wcpV0+rpMM7sw5RZxFafHmToYlVRJgvlN+vMJIw5sDVDHgmb7NRILmh8+3Bo+GmYps QvBXEyIVVFKnpVc3YB47qanmQdrDKegpdQhMxp8jt5q2nZ65mmBAyd/UnIAd0ZsKaLi3j7pbK XMNlnVk6CcuASoN8wJ/s3CW8QoM/k2RUupYOxZltBSH1rGp/1N7DiPBrbR4GxCJjU3Rs+66aS 5e1OTOR5jAssvFnRybIX065kODmDcyJy8luJ7fy+KALPIbhcRov81Bg+Fw14oHK6EavQX+WWf iK7dI+iyUnvQw51h0966rfoSjCkzWa841TxYvwnkBmsZe0lBmDHUK3ly2eCfdaRAkWpmIKvQ6 X/hia2NqViw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Phil Sainty writes: > Agreed. I think the remove syntax is all but unreadable: > > (setf (alist-get KEY LIST t t) t) > > to remove items from LIST with key eq to KEY. > > Unless accompanied by comments, I do not think that meaning obvious > at all. > > This variant gives a better idea... > > (setf (alist-get KEY LIST :remove :remove) :remove) Yes, the syntax is a bit weird. I think I would prefer to write it as (setf (alist-get key my-alist nil 'remove) nil) The syntax also makes some sense: If you set the association of KEY to the default that `alist-get' would return when the entry would not be not found, the entry can be removed. But I agree we should add such an example, since not everybody wants to meditate over why this makes sense in order to remember the syntax. Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 03 10:52:04 2019 Received: (at 34708) by debbugs.gnu.org; 3 Mar 2019 15:52:04 +0000 Received: from localhost ([127.0.0.1]:58642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0TPH-0003bE-Vb for submit@debbugs.gnu.org; Sun, 03 Mar 2019 10:52:04 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:33334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0TPG-0003aj-CC for 34708@debbugs.gnu.org; Sun, 03 Mar 2019 10:52:02 -0500 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 x23Fn7x2071631; Sun, 3 Mar 2019 15:51:55 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=9fBRgqCKOM+7VNIUiBLrf3Yda7m+razGxw1o4wyQnFo=; b=WWDtAupPWT/kiyHK2vTI+3fupaif4X4uuCFW8nuUHOMa/CkIbYprPcPkgK339hXSFDy7 rcQeNfbjHoUeJwojlRbISO6Zb5QJqf9AdXn+MLGunWeaJxpKK+xg9XLgv7GxTwv62K3S Y875bkLleMWY5D8GgZpU6CD8l4BUF5nGxTH2e14Md8TnKQgvP0oPHaQktKK6LbXRbqK+ dO9xOdEEDqGapiu/7OTdXN2tNbTVNteUz6VebvbX6aCu5ZLS/X08EBt8GWNlkwS5R9jP 1nEDPXrQZGPg3q3LwKCVehLbJD0+TO+UDcBMEkt6DDUAPdjJ1Wdw7UIpssS2vH2zhwrc Vw== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2qyh8tuepe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 03 Mar 2019 15:51:55 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x23Fps7k004567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 3 Mar 2019 15:51:54 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x23FpqSH002409; Sun, 3 Mar 2019 15:51:52 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 3 Mar 2019 07:51:51 -0800 (PST) From: Drew Adams To: Michael Heerdegen , "Miguel V. S. Frasson" Subject: RE: bug#34708: alist-get has unclear documentation References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> <87mumcdu7f.fsf@web.de> In-Reply-To: <87mumcdu7f.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9183 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=1011 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-1903030125 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > I think the sentence below is a good and short explanation for the > > doc-string. > > > > The return value can be conveniently used as a generalized variable Lose "conveniently", please. > > (a place) to set the value associated with KEY in ALIST, like in the > > example (setf (alist-get key alist) new-value) >=20 > Thanks for the idea. I don't think we should explain it like this > however, because when evaluating >=20 > (setf (alist-get key alist) new-value) >=20 > the function `alist-get' is never called, so there is no return value. Yes. (But that text didn't say it was called, and it didn't mention a return value.) `setf' is a macro. Its PLACE arg serves as a _specification_ of a place (a "generalized variable") whose value is to be set. And "set" means create or update. It's not really about `alist-get' here; it's about `setf'. `alist-get' itself has nothing to do with using a generalized variable. > Of course what is sexy about place expressions is that it looks like > you would directly set the result of a function call, but what happens is > that setf doesn't evaluate the call but analyses it and builds and > evaluates code that leads to this result. Yes. But that's "just" plumbing. It's not important to explain that here, I think. In terms of describing the role of `alist-get' as a `setf' place it's not relevant, at a first approximation. That `setf' doesn't call `alist-get' but instead analyses the spec and builds code that does the right thing is not necessary for getting the main point that `alist-get' can be used with `setf' to specify an alist element to create or update. > Eric suggested to say "this form is a setf-able place" but this also > doesn't answer the question what this (form) is. `alist-get' is not a > form, it's the name of a function. In my opinion it would be cleaner > to say something like "the name of this function can be used to build > place expressions" or "can be used in place expressions" or so. > Better ideas welcome. Yes wrt the substance (content). But an active phrasing is often better than the passive "__ can be used". Say what this does by saying what you can do with it. You can use function `alist-get' in a PLACE-expression argument to `setf'. In this role it specifies an alist element whose value `setf' sets: (setf (alist-get KEY ALIST) NEW-VALUE) Here, `setf' sets the value part of an element of ALIST whose key is KEY to NEW-VALUE. It's important to not give the impression that there must be an _existing_ element with KEY. Showing an example can help dispel that mistake. (setq foo ()) (setf (alist-get 'a foo) 1 (alist-get 'b foo) 2) C-h v foo ; =3D=3D> ((b . 2) (a . 1)) From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 03 11:49:24 2019 Received: (at 34708) by debbugs.gnu.org; 3 Mar 2019 16:49:24 +0000 Received: from localhost ([127.0.0.1]:58660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0UIm-0004yM-BU for submit@debbugs.gnu.org; Sun, 03 Mar 2019 11:49:24 -0500 Received: from ericabrahamsen.net ([52.70.2.18]:34624 helo=mail.ericabrahamsen.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0UIk-0004y8-1r for 34708@debbugs.gnu.org; Sun, 03 Mar 2019 11:49:23 -0500 Received: from localhost (97-126-72-117.tukw.qwest.net [97.126.72.117]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 1C095FA02D; Sun, 3 Mar 2019 16:49:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ericabrahamsen.net; s=mail; t=1551631756; bh=uwmMvbv6ZY5wra/VhzPWoZJxMvr3qmGWzvKBIiXvYXU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=tAoYL1tyEwFo7Adb4IZ7TCSkM4DInskyHVRxDjUK8D3yNzffHAx4kmIn2bjT48F99 7DHAaMDgZ/vY8bJxZ6hTE+hkdCM+X4KcxMBM01A7zJmacb+V2JuwZpHdkS1ak7/gm1 t4ysX8/Kk6sia0Qgb8Q0+cCPQO4UJWaIrA9O+gcA= From: Eric Abrahamsen To: Drew Adams Subject: Re: bug#34708: alist-get has unclear documentation References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> <87mumcdu7f.fsf@web.de> Date: Sun, 03 Mar 2019 08:49:14 -0800 In-Reply-To: (Drew Adams's message of "Sun, 3 Mar 2019 07:51:51 -0800 (PST)") Message-ID: <87zhqbhpit.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34708 Cc: Michael Heerdegen , 34708@debbugs.gnu.org, "Miguel V. S. Frasson" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 03/03/19 07:51 AM, Drew Adams wrote: [...] >> Eric suggested to say "this form is a setf-able place" but this also >> doesn't answer the question what this (form) is. `alist-get' is not a >> form, it's the name of a function. In my opinion it would be cleaner >> to say something like "the name of this function can be used to build >> place expressions" or "can be used in place expressions" or so. >> Better ideas welcome. Well I used "form" because it _is_ the form -- (alist-get KEY ALIST) -- that is the setf-able place, not the function/macro/name of the function. At least as far as the coder is concerned. > Yes wrt the substance (content). But an active > phrasing is often better than the passive "__ can > be used". Say what this does by saying what you > can do with it. > > You can use function `alist-get' in a PLACE-expression > argument to `setf'. In this role it specifies an > alist element whose value `setf' sets: > (setf (alist-get KEY ALIST) NEW-VALUE) > > Here, `setf' sets the value part of an element > of ALIST whose key is KEY to NEW-VALUE. But I like the above better anyway! From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 04 11:24:28 2019 Received: (at 34708) by debbugs.gnu.org; 4 Mar 2019 16:24:28 +0000 Received: from localhost ([127.0.0.1]:60113 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0qOC-00089M-5J for submit@debbugs.gnu.org; Mon, 04 Mar 2019 11:24:28 -0500 Received: from ericabrahamsen.net ([52.70.2.18]:37064 helo=mail.ericabrahamsen.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0qO6-000891-Cs for 34708@debbugs.gnu.org; Mon, 04 Mar 2019 11:24:24 -0500 Received: from localhost (97-126-72-117.tukw.qwest.net [97.126.72.117]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 3EB5BFA035; Mon, 4 Mar 2019 16:24:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ericabrahamsen.net; s=mail; t=1551716656; bh=KYURVqEIuv8THbPqSfdCU/sJc3pwxIJfjZRfyvzvVpA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=JXb2eBncVHVBaiaf0f6xIkdgyGj99gHurYIVAm1A1fj4M+n42et6jRLBUs+ZmWF6U NBTZQa25hveAzeXadZXLGPQDR/B/IqH6CYd5gUpTWA3/ZUuX81kVpyF+EMKsbo1oeg Z4LsLZ7xEG+K2oxTfGni9NH3mzJcGAFigZ7CUa8Y= From: Eric Abrahamsen To: Drew Adams Subject: Re: bug#34708: alist-get has unclear documentation References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> <87mumcdu7f.fsf@web.de> Date: Mon, 04 Mar 2019 08:24:14 -0800 In-Reply-To: (Drew Adams's message of "Sun, 3 Mar 2019 07:51:51 -0800 (PST)") Message-ID: <875zsyhakx.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34708 Cc: Michael Heerdegen , 34708@debbugs.gnu.org, "Miguel V. S. Frasson" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 03/03/19 07:51 AM, Drew Adams wrote: [...] > It's important to not give the impression that > there must be an _existing_ element with KEY. > Showing an example can help dispel that mistake. > > (setq foo ()) > (setf (alist-get 'a foo) 1 > (alist-get 'b foo) 2) > > C-h v foo; ==> ((b. 2) (a. 1)) I think it would be nice to have an example that shows both a common use-case (as an accumulator), and how to use REMOVE. I started off with the accumulator part: (let (word word-freq) (while (setq word (pop word-list)) (cl-incf (alist-get word word-freq 0 #'equal) 1))) But so far haven't come up with a non-contrived way to work REMOVE in there... From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 04 11:39:16 2019 Received: (at 34708) by debbugs.gnu.org; 4 Mar 2019 16:39:16 +0000 Received: from localhost ([127.0.0.1]:60130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0qcW-000059-4i for submit@debbugs.gnu.org; Mon, 04 Mar 2019 11:39:16 -0500 Received: from mout.web.de ([217.72.192.78]:36315) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0qcT-0008WU-Hs for 34708@debbugs.gnu.org; Mon, 04 Mar 2019 11:39:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1551717538; bh=Rtx9/5JYcTol+ID0VzLcKTemTbJZ4CYzELZhJXeVZCo=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=ehNvm5PyTPs+a+Tr8MWyuwVek0pwTuuSVmX2Qh1IBZlX9icdGnnLVaBCb5zEJ0tU7 DfZ/TLcUHmQN9nyv6Zw7B9mprDYoiUfEjd5ztgthTTM97xoAJtVzHMeOieUDpilEdO AUQTC5dS1v0TbrzVS45ILVL+vbZAw7hFiZjPP6e0= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MEmoQ-1gm1hg1hN4-00G0UJ; Mon, 04 Mar 2019 17:38:58 +0100 From: Michael Heerdegen To: Eric Abrahamsen Subject: Re: bug#34708: alist-get has unclear documentation References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> <87mumcdu7f.fsf@web.de> <875zsyhakx.fsf@ericabrahamsen.net> Date: Mon, 04 Mar 2019 17:38:57 +0100 In-Reply-To: <875zsyhakx.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Mon, 04 Mar 2019 08:24:14 -0800") Message-ID: <87fts2h9we.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:VEJiTcxB6de8RkQb0DFlQyxHu1PUknmv8TrrcO2u4z3ctK3jbt2 j7veGVsztcDKzWSlprC+jmtHFOg5Lfk6MioimlXgSq/YAIQmBolQh1XZfJNAVo9YdH+5oaD sWXtOwk/bzOZLrMiYc+g8FczxvZ5TBtzGX4LHn6kvbETmLHlkcKuRB4gydt9q2jQkTIM7f1 uL/VMdbyuSycHOhac5xhA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Pcp7DTRhbWY=:JImsD8t3UyJRRImg0wHlQp 2peDQY66T6uAMQzgEaRRaD4kZE+8R+ziGuSpWV+Qgpx1LOW2SYoOERKrXg3GBCIqFC5Q7NtZW R1l5RZO3TPUadtvfRgqkq6ob9oxp/Or3lse5ZWa30O5NMfkFF4yTKBpWN42t9KXcCvjPM0zto PU9psJbB+CosM9vxK0z8PUhTlgvdQFa2Tb2PK0yw8dyL2U6gyvT6koQKrdaZjk0aRXXRWwQdq fylhhKXaZUnXk8bpipdX4ZGUxKuR63xjdjRrZ27XXgvB8xozPtrHpKai4rc8acBYYTVaeJhOl sWtyXX7oXJ14/q8sbccS9wuB5kNnuFqzlS0enCwlTpxFG2U2TDC1w9vpUdcC9ciJcA4wx0sdk Anxb1eJXCIcufKs+4wVUcLFdHoNYKoFEzYuGDDKwViInPK/eUi8tCxK5Stqr+HqM6FTllfzx0 s7N3kW3u6dAPdSkUJtBr+m+44StfR4XA7zYESFEaikkNi8SBF93hALI4oiQu7xsmVZ983CyMD O7vBToLBBUQDFGv/RVIekziU6a8J9OlsZIucaEGNSqO5lxEaUrFMiZGzRTWyKPVMoYrFu9KmB UZ5G8/hNA3/ttEGulqbFwkDStdqvw4mszMBfFcPztMgTb9oru+nDJTHtYcq8n1QJpCJKzIkrP reaZKIEzfbvkHvM6LYTPHOzRwsMvxq1z+f+2JCMAg8Sbn6GzHFDOSb8pDsbaRD9vMPLNL4//v IU0RW6ytQyCu+DkdcfO7GHN+jwYj/q7rwv0blmzHHsuO34EPXamG3EzoWQIuqI2NT8DZI0msP hPGgWggC371OOuaMy0NKBBOw2TvsqdgD9GsmHF0rhqA+zyaVuE2+VDlth3uBZINvRtyblQg6D oaQ26qfAObx9uxKKcMrkPrYQumoJaQ9+zpQgJGO8Tk71PCX/jnwfnWJ+RwqoBz+zCa9cARu5c k/CUXZ0rZug== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eric Abrahamsen writes: > I think it would be nice to have an example that shows both a common > use-case (as an accumulator), and how to use REMOVE. I started off with > the accumulator part: > > (let (word word-freq) > (while (setq word (pop word-list)) > (cl-incf (alist-get word word-freq 0 #'equal) 1))) > > But so far haven't come up with a non-contrived way to work REMOVE in > there... And I guess you didn't really want to specify a function as REMOVE arg, right? Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 04 12:16:55 2019 Received: (at 34708) by debbugs.gnu.org; 4 Mar 2019 17:16:55 +0000 Received: from localhost ([127.0.0.1]:60140 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0rCx-00015i-FO for submit@debbugs.gnu.org; Mon, 04 Mar 2019 12:16:55 -0500 Received: from ericabrahamsen.net ([52.70.2.18]:37210 helo=mail.ericabrahamsen.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0rCv-00015T-Md for 34708@debbugs.gnu.org; Mon, 04 Mar 2019 12:16:54 -0500 Received: from localhost (97-126-72-117.tukw.qwest.net [97.126.72.117]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 88646FA035; Mon, 4 Mar 2019 17:16:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ericabrahamsen.net; s=mail; t=1551719807; bh=wAngsfubmE5k+QqtiEmC0GNuAToDS0p6t6RluNVvuVE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=U5JveavitcTIKUW27DfDquHHXlaj6QICsy4+wtd1Ug246P20SznCvPG/qg5tD6YS5 6b82YcoRMyxMFQQvPTFa9yeHVCraHpKcYmljKPx9+ryLiIofXm5QltgiiXxgT6iy+y 4aRWmVLxHMaT5S+AWy4It8xXfwPuvZwKSE1s1lG8= From: Eric Abrahamsen To: Michael Heerdegen Subject: Re: bug#34708: alist-get has unclear documentation References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> <87mumcdu7f.fsf@web.de> <875zsyhakx.fsf@ericabrahamsen.net> <87fts2h9we.fsf@web.de> Date: Mon, 04 Mar 2019 09:16:46 -0800 In-Reply-To: <87fts2h9we.fsf@web.de> (Michael Heerdegen's message of "Mon, 04 Mar 2019 17:38:57 +0100") Message-ID: <871s3mh85d.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34708 Cc: 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 03/04/19 17:38 PM, Michael Heerdegen wrote: > Eric Abrahamsen writes: > >> I think it would be nice to have an example that shows both a common >> use-case (as an accumulator), and how to use REMOVE. I started off with >> the accumulator part: >> >> (let (word word-freq) >> (while (setq word (pop word-list)) >> (cl-incf (alist-get word word-freq 0 #'equal) 1))) >> >> But so far haven't come up with a non-contrived way to work REMOVE in >> there... > > And I guess you didn't really want to specify a function as REMOVE arg, > right? Don't you think it's confusing enough already? :) Though maybe there could be a second example showing "advanced topics in REMOVE". While we're here, you mentioned up-thread that REMOVE isn't intuitive if you don't understand what the DEFAULT arg is doing. Obviously I don't understand that: would you elaborate? Thanks, Eric From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 04 13:22:47 2019 Received: (at 34708) by debbugs.gnu.org; 4 Mar 2019 18:22:47 +0000 Received: from localhost ([127.0.0.1]:60157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0sEg-0002cq-F7 for submit@debbugs.gnu.org; Mon, 04 Mar 2019 13:22:47 -0500 Received: from mout.web.de ([212.227.17.11]:43419) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0sEe-0002cW-2c for 34708@debbugs.gnu.org; Mon, 04 Mar 2019 13:22:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1551723749; bh=8LLff89G2mGR6htJ9l17EKG+fK49PTOwrSAGTHKDQSE=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=kli3rAtwDNgIKLGby+BxbQgVnucJg4kl8vUXcIkbleBEiXRQoLiHuWQFily/f1IsN wSxF8zJucm8l05Or/DvzG7q3PIAWot0H8d1dlVpV/l7e19F2rbi3lezCBOZ4W7Xbmt dPWLzFJuO3XHStFs7JUbWxuKW+SvR/UkCrli3JDY= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0Lz3FM-1h5K9l20X2-014FQf; Mon, 04 Mar 2019 19:22:29 +0100 From: Michael Heerdegen To: Eric Abrahamsen Subject: Re: bug#34708: alist-get has unclear documentation 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> Date: Mon, 04 Mar 2019 19:22:28 +0100 In-Reply-To: <871s3mh85d.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Mon, 04 Mar 2019 09:16:46 -0800") Message-ID: <874l8iebyz.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:3pETMjPqRNJEfwsCWvaXM1lANYNuzr8cfL+RH81m3JJbQbuqcoo QO9RlhO8W0PU66NYkZgipVAS0GCuLTKleWx9ulL7cG2jpGcvt8WXqPvOxDfr1xunIY5vjtz K/7Jpp4HAzzIa9WQsNLzvFpD3J6YXzy+3Q2Yz0TKoourIRyMR+CsiWeO0ey7OIc8tOWXqra VzRlkepQJzCFzQVvhx4ng== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:ZdXDALwK7oE=:scKcHVHt7E390sCNeGLkVN 0hrLYazCZrX+ss99qN/9xFDn6pW7d6yRRbGmtd45saCp9PeX/2b5XKhnVSEfD83+ppo+3Jj7m eOONiaUvJv4hnE4RiUWXbufSnfUg+ViDADY5cUN94xV4MbUwBEg+cof45Ly7h/ayJcS+R+NuB 2zYscADC3Ntd2cvuSeJFyMyh+hsP0r1Bpjq2BEJUUklR5HswmOkLIbmWMBAccE/7tKV0jcHW8 UnNTfvzyP64gjRyc62jOSUCILsofOnSp5KwjKQ+AZwqQUZagn1vA5AmN6ISi7K0n5vJXh/wxd yPxLRvaF8PgNkC9vRKk+DJZXyyyBM8lNC/YznZV7ppMkT9WRIdfQup9kxdfxVkmy9DMZI2qeM jqFDMzFQ80CBZGURyQFzLuaJbr9wUj8t3WEMidKKX3dPR4dgz3n+ms7+qPTdG7QaTCGZZ0/ci oShkqP6cYwCyGfCb5+tXxnBkWPNmujFrjhTdyNRTypJSFyZju6wSboM0P5NFLaTFQwPdyVGho 3nRsCX26Pm6kQSKX+A0G1HnQNa9FzhQuiNq7Y3yYLu543wNDqsbS2tlkuNmH7WXv5rTOQiRyt D1zPY4P1QkVu21YDFEICNRcaOEykt4ou9vAdtydfhIl4FSGSAgPseiuklmv0UrOt2vm9q9SaT tN5b8IQRkhUcyqQPSjI4fYr87Y7JFgSalzis3QXXmrf3l5cRq/B1ks+ttFlx3iJ1Nztosvq9D ez7PyeV4yftyIaa71CJE7P/hKTTHdgJfbcQR9PxsI8o5mOkKaeS66CkVp/PYisTQBi3mii66a bSfkUtfWEHo1eEI6EMOWL+clVI1JWMbnbK4KInOU9pP4rIlyvGk8GfRvImYbSzYp926rERe9E z8CT5Pg8jRV1pdiE7bDE7sFVQWiXz6CCDOv9iTpJ0Vi55bx5ADnTL3nWuE1qUldGGaVKbcezQ Iw6PFk96BMQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eric Abrahamsen writes: > While we're here, you mentioned up-thread that REMOVE isn't intuitive > if you don't understand what the DEFAULT arg is doing. Obviously I > don't understand that: would you elaborate? Ok, I try to repeat with different words. Too many words, sorry. What I wanted to say was actually simple. In most cases what (setf (alist-get KEY ...) ...) should do is clear: change the association of an existing key, or add a key-value association. In case of using the DEFAULT argument - we don't yet speak of setf at all here - (alist-get key alist default) returns DEFAULT if KEY is not found. But it also returns DEFAULT if KEY is found in ALIST and happens to be associated with DEFAULT. This makes a call like (setf (alist-get key alist default) default) ambiguous: the "goal" (which is making (alist-get key alist default) eval to DEFAULT) can be reached in two ways: (1) by making KEY being associated with DEFAULT in ALIST and (2) by removing any existing association for KEY. You can choose which behavior you want via the REMOVE argument which comes after the DEFAULT arg: specifying REMOVE non-nil gives you (2) - remove it - else you get (1). BTW, a simpler way to delete an association in an alist is (setf (alist-get key alist) nil) This will do most of the time unless it's important that the alist doesn't grow too much. Maybe it's because of this that the remove facility is a bit hidden. Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 04 17:49:27 2019 Received: (at 34708) by debbugs.gnu.org; 4 Mar 2019 22:49:28 +0000 Received: from localhost ([127.0.0.1]:60373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0wOl-0004g0-KX for submit@debbugs.gnu.org; Mon, 04 Mar 2019 17:49:27 -0500 Received: from ericabrahamsen.net ([52.70.2.18]:37898 helo=mail.ericabrahamsen.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0wOi-0004fl-Gb for 34708@debbugs.gnu.org; Mon, 04 Mar 2019 17:49:25 -0500 Received: from localhost (unknown [207.109.85.82]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 8FB3CFA02D; Mon, 4 Mar 2019 22:49:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ericabrahamsen.net; s=mail; t=1551739758; bh=e9CcJv3XN96t819Q8ESMXOKyLMowcW9k1w7AY/o3yIQ=; h=From:To:Cc:Subject:References:Date:From; b=IKplO2MT0FklOmeDp/6GtRn8Cv9XWeDr1aGHJ8Sg9QBRPiVIBvs/gakS2mTINb20e MyX9QDexpV6n7MZOwaOT0zWDcdP0wk4cBUkj0v3NijChA5ZUHnBs707X91JtRIob3l VhpIkQWm28Pajp4ZPV2zN4vg+2dxsN0Z+zoHBN74= From: Eric Abrahamsen To: Michael Heerdegen Subject: Re: bug#34708: alist-get has unclear documentation 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> Date: Mon, 04 Mar 2019 14:49:15 -0800 Message-ID: <878sxui7bo.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34708 Cc: 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 03/04/19 19:22 PM, Michael Heerdegen wrote: [...] > This makes a call like > > (setf (alist-get key alist default) default) > > ambiguous: the "goal" (which is making (alist-get key alist default) > eval to DEFAULT) can be reached in two ways: (1) by making KEY being > associated with DEFAULT in ALIST and (2) by removing any existing > association for KEY. > > You can choose which behavior you want via the REMOVE argument which > comes after the DEFAULT arg: specifying REMOVE non-nil gives you (2) - > remove it - else you get (1). Thanks for spelling all this out! I guess my confusion is the interaction of REMOVE with DEFAULT. Why does REMOVE only do anything if the value being set is equal to the DEFAULT? If they are not equal, REMOVE is ignored, and the value is set. How does that make sense? From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 05 07:36:09 2019 Received: (at 34708) by debbugs.gnu.org; 5 Mar 2019 12:36:09 +0000 Received: from localhost ([127.0.0.1]:60626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h19In-0001Rd-6n for submit@debbugs.gnu.org; Tue, 05 Mar 2019 07:36:09 -0500 Received: from mout.web.de ([217.72.192.78]:34183) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h19Il-0001RL-Ik for 34708@debbugs.gnu.org; Tue, 05 Mar 2019 07:36:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1551789353; bh=lXbn+jRHEbAu6oU2ayMX0yH6FcPJFQLXzIydq/LyFec=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=U+aeZ7+KhBn8Gw8PyfR+uggyfMHoOSNLfMhsNjRmQtdpEo5qlkfeS6o2eqADD/nyy rrWXDG1x1+1cbzDRUCUSMZKiAxTQOGwdZVe3YpDPf4y0y+z6Ze5TU2Sp+VxEaNXtRq X+o17rqw02oyFlFE1p0D8YRSkqDA5Rou9KH4bTMo= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MZUWH-1ggRW805c5-00LIEA; Tue, 05 Mar 2019 13:35:53 +0100 From: Michael Heerdegen To: Eric Abrahamsen Subject: Re: bug#34708: alist-get has unclear documentation 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> Date: Tue, 05 Mar 2019 13:35:51 +0100 In-Reply-To: <878sxui7bo.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Mon, 04 Mar 2019 14:49:15 -0800") Message-ID: <87va0xcxco.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:mebrm9zXJztpUrX1yadQfhgTiSBRDyDendU+tcvrXgb/IUMk0E5 MPwJqrBS+BSjP8FT9FMQLVnkgfYAJlXrT+Lissw+ibRKMRzoFKs515zRZf9Podq8X+TzyWz IZLl3B76n2I1Bnlk2AiEDw8BSMrxY0cJ6Uy/HCJQnRCsuQyoWV5DZle1PESMOeTMJHwkPDo F5caTQrq9VkQGCSL77meg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Kbk5RN6PoFE=:glz5vVU7AgMuKMEeMlstRS bMPfcoMdKICVo6Qefumg63Ce9c4mpsZVBU8FS+RPJBTJSDD4wqlxU1eoC2WGYlJUZpxIXiSVA uxk0yhhrEwtQrn6OvE03hRgobEwL68ZYQ8vhXBFreFkDsKA6UlBIsV0l6s/1S86g969L4yIfi YE+hmV/30QM3VGaOI5utKrxtCXkpvaYa7qmfuSMcfTj/760eqdh9+AtY9qx/WIiLbbC/ZN9Zi zudqleGhXQXdbRrrw/JiGmgd5MYwvuGgAG77mEgw7yGmbgMPj7ygRrq6kaI+1KH7lC7TQEaJ7 NsDaEkQ6X/nhjxUoIpqorkPzAq/CFwjH4FNoHk8Xl3TwcW7tmuYc7zkWYSf8suEDLIoABfs+U tjgn3CFdJmZgcyWIPDMlsdTFzmvB8kORc8FkhG8cdVVDSp6ulCHHnn9pkbVOUQuKbOTrfjqhx mo3HT2wnjlR/6RyiNoF619NwiPYUo3Csgmb1ghMoTrUJOMf+WPwCxJYi2uC5GFNAFUs0APIfD DNa0SfmwqPCSO9vs3I8zGCKNW+mWoInCT9POi3L1YJ1z3qmozNFOCcjGoKZJ4GOnv2Go3dABO HvM3IvcFo0deX3g3LE0slLnf1fDnkLsNvr/FMgK01s/rRAZ35K7ifA7TSAgavX75B4nE/SJWS C8A0HzB+XCor70kffbdA40tYZmqqK9nSPPzcfhmVFortn0BWuZ9ga42LGv+v7kcEfw2yFd4Qp 6h45KWY3AIXD8T/T0N1g6Yjhs1TIRhFr5tdqa91juSPa3SriaZiJesbxVIV5aG1ntEUffZ4IL Cun2sQ+TDBd6HGCffSWL2d45VNf/EzOzQRgHc+R6kNf/86gmSO7y5HKAma2pjGa7pDuyvCdex AXsVhlcbF5nVDZgBrDU6K+5GT89Vh0SKgNNFS/d6LZxemCqE5Jyd1GTw2kxd6uN4Ctw3LsxJH NZ5szNDL3qg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eric Abrahamsen writes: > Thanks for spelling all this out! I guess my confusion is the > interaction of REMOVE with DEFAULT. Why does REMOVE only do anything > if the value being set is equal to the DEFAULT? If they are not equal, > REMOVE is ignored, and the value is set. How does that make sense? If you do (setf GV V) with some place expression GV and some value V, you expect that afterwards GV evaluates to V. If (setf (alist-get key alist nil 'remove) t) would remove the association of KEY, (alist-get key alist nil 'remove) or (alist-get key alist nil) would not eval to nil, although you have set the place to t. With other words: removing elements from an alist is something that doesn't fit 100% to place expressions, so the syntax and semantics you get are not 100% straightforward. Not super sexy, but consistent. Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 05 17:50:58 2019 Received: (at submit) by debbugs.gnu.org; 5 Mar 2019 22:50:58 +0000 Received: from localhost ([127.0.0.1]:33577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h1Itm-0004dN-2x for submit@debbugs.gnu.org; Tue, 05 Mar 2019 17:50:58 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42519) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h1Itk-0004dB-OA for submit@debbugs.gnu.org; Tue, 05 Mar 2019 17:50:57 -0500 Received: from lists.gnu.org ([209.51.188.17]:45302) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h1Itf-0001oz-FK for submit@debbugs.gnu.org; Tue, 05 Mar 2019 17:50:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1Itb-0007sT-Tg for bug-gnu-emacs@gnu.org; Tue, 05 Mar 2019 17:50:51 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50,RDNS_NONE, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h1Ita-0001k9-OE for bug-gnu-emacs@gnu.org; Tue, 05 Mar 2019 17:50:47 -0500 Received: from [195.159.176.226] (port=40972 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h1ItY-0001fz-T7 for bug-gnu-emacs@gnu.org; Tue, 05 Mar 2019 17:50:45 -0500 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1h1ItT-000Eat-LS for bug-gnu-emacs@gnu.org; Tue, 05 Mar 2019 23:50:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Eric Abrahamsen Subject: Re: bug#34708: alist-get has unclear documentation Date: Tue, 05 Mar 2019 14:50:33 -0800 Message-ID: <87h8chey12.fsf@ericabrahamsen.net> 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> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cancel-Lock: sha1:OmEI4ISIfc6dAAiz0SLpzDHKrKY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Michael Heerdegen writes: > Eric Abrahamsen writes: > >> Thanks for spelling all this out! I guess my confusion is the >> interaction of REMOVE with DEFAULT. Why does REMOVE only do anything >> if the value being set is equal to the DEFAULT? If they are not equal, >> REMOVE is ignored, and the value is set. How does that make sense? > > If you do (setf GV V) with some place expression GV and some value V, > you expect that afterwards GV evaluates to V. > > If (setf (alist-get key alist nil 'remove) t) would remove the > association of KEY, > > (alist-get key alist nil 'remove) > > or > > (alist-get key alist nil) > > would not eval to nil, although you have set the place to t. > > With other words: removing elements from an alist is something that > doesn't fit 100% to place expressions, so the syntax and semantics you > get are not 100% straightforward. Not super sexy, but consistent. Okay, I guess that makes sense, thanks. But we still need some more examples in the docstring! From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 05 19:16:35 2019 Received: (at 34708) by debbugs.gnu.org; 6 Mar 2019 00:16:35 +0000 Received: from localhost ([127.0.0.1]:33618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h1KEd-0006j7-EE for submit@debbugs.gnu.org; Tue, 05 Mar 2019 19:16:35 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:50908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h1KEa-0006ip-Ix for 34708@debbugs.gnu.org; Tue, 05 Mar 2019 19:16:33 -0500 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 x2603ZR2138846; Wed, 6 Mar 2019 00:16:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=A+SlZ38q9YEc3rEuoySfNW8pddfWqWJn6NfO3J8LTB4=; b=5b9Y27fp0szP/h2mBWTVOoCYUGH/Y1BBNAfcPMUCl3KBvCQ1fzLnfbS/szdGMqHugs1C aX+c+Stqo8q3konuBU4CZI4HfL+2LmZzIeXn94oH7GzX74MPFvY4PoUCZBBro9RWKpzI s66YGIKxZN/RjofCbT83v+TA01Cx9YOfxKc6Z6zSjklcvPPvNj1/w0OeqAh07EF7Oks0 0SGDHS7+MH85VyAs3I9FON5zg2MIHSe0OwB3ue8hIleJquK7o+vK7IPVJlIux2pZd3FZ J5u+Ev9iRqficG2jYYrv8qe/+cQorwXQrA5mur7KH2+sWaynsOseRMwdJO6kBMMkJcVK dg== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2qyjfrgp60-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 06 Mar 2019 00:16:25 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x260GNQW020594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 6 Mar 2019 00:16:24 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x260GKY3011258; Wed, 6 Mar 2019 00:16:21 GMT MIME-Version: 1.0 Message-ID: <60367f47-c0b0-45b4-8ccf-169044400a75@default> Date: Tue, 5 Mar 2019 16:16:19 -0800 (PST) From: Drew Adams To: Eric Abrahamsen , 34708@debbugs.gnu.org Subject: RE: bug#34708: alist-get has unclear documentation 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> In-Reply-To: <87h8chey12.fsf@ericabrahamsen.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4810.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9186 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=908 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903050155 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34708 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Getting from an alist the value for a given key is straightforward, obvious. So presumably, wrt getting, `alist-get' doesn't have to say more than that's what it does. But _setting_ a value for a given key in an alist is NOT straightforward. (An alist is not a hash table.) Often (typically) it means just consing a new alist entry on the front of the alist. (That's pretty much the main reason to use an alist.) But you could alternatively first remove one or more existing entry for that key from the alist and then add the requested key+value entry. And if you remove _all_ such entries first then you don't necessarily need to add the new entry to the beginning (though you almost always would, other things being equal). The ambiguity wrt setting means that the part of the `alist-get' doc that talks about using it with `setf', to set the value of the key, needs to be very clear and correct wrt the implementation. If the implementation just tacks on a new entry at the list beginning, then say so. If it does something else then say what that is. It's not admissible to just say that it sets the key to the given value. Why? Because of how alists are used. Code can very easily make use of an alist if it knows how it is being maintained. `alist-get' is a general function, and its doc needs to say something about how `setf' sets the value (what the result is). Similarly wrt removing an alist entry for a given key. Does it actually remove all such entries, or does it just tack on a new entry with value nil at the beginning of the list? These things need to be specified in the doc. 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. A user doesn't necessarily care about the "how" details, but s?he deserves to know the "what": What is the result of setting the value of a key or removing a key? From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 11 09:39:22 2019 Received: (at 34708) by debbugs.gnu.org; 11 Mar 2019 13:39:22 +0000 Received: from localhost ([127.0.0.1]:38684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3L9G-0000Fz-KU for submit@debbugs.gnu.org; Mon, 11 Mar 2019 09:39:22 -0400 Received: from mout.web.de ([212.227.17.12]:37851) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3L9E-0000Fl-Ch for 34708@debbugs.gnu.org; Mon, 11 Mar 2019 09:39:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1552311542; bh=10lAdSq3xkbcZlPuSrsBtEzSceTMtb4Arerj7z+W/rc=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=hbium+zfEOnLYp1Bx48zq94W71+inVxLtSmnKxX0f+/2yV1tp4z7vUHMoKmPTIjLR DALszbJL90pEWA49mVmj9WpVGIiBpYzJIj5QLuEEtxww3ijXP1q2LKw8bOAQzhVT1M 0G8VarPlULSNw+PfH3TVxPp/s8/e2LZxmQxyKSy8= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0M9os0-1hEJUj3Anw-00B39j; Mon, 11 Mar 2019 14:39:01 +0100 From: Michael Heerdegen To: Drew Adams Subject: Re: bug#34708: alist-get has unclear documentation 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> Date: Mon, 11 Mar 2019 14:39:00 +0100 In-Reply-To: <60367f47-c0b0-45b4-8ccf-169044400a75@default> (Drew Adams's message of "Tue, 5 Mar 2019 16:16:19 -0800 (PST)") Message-ID: <8736ntmsy3.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:xtpZayRRDxMzQQRl/Ato6leN2o+EDQU5aCGx5nLh9xebbe3v57J k3fDu/u1dEq3ScS5scB5FOBCxPm0Zk0XmdiHBv+jYapnLtfnAUDV5urNiBs0gozS1gsclgL 0iqrv9KD1meuy6wQf1obLgMp2cJIf11BHlLsPasBds5HtDwKPMTActx2d4di9fvEWcnLmbG 7MyBtPt1lcyG5Y9CCQhqw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:ZUQe67MMe3Q=:lAypgItYVDon0A9euFzKSh aZo/Efu6wAieinoJDlvI3krtR/Xflztr+ZbN/RtTxrrL34udpm4p1MW6UGEDYnuZ7Tgxe+eno aTQXfjcf/INmwGZ5/6Wa+7W5pFUoYMLuA2fETndgvo1hr+CZSfCY7sX9GGF6M+ct9KOceCIOL sM/jUw6D9SKNMi/wjVMxhdHKYKWSXD3P2ewfYL2CKbIYIblibZzX7E4fYeMcyP3doBPiq3C0E 9P2lupXDOGLq/nef/uW1OWIsSGKMGIiFcNHteIN+AqxMnbggRN3cevGYcaGthElX9iKbuxLG0 idrMgPvaZ7KF721AKN2hZbm8y7AhrvRG4g4yvv2mZrdcESqpj/4U9YcK6JzdbsBGnZiOAidqo FOjeqen7IzcMxMwJx94gwsoKgSyZBd1DXj/vsRzbzSD4Mlglym1jKd2bnu2OVzqJyMDEPs1FE 2gbnPRbqTP4GpjEjFvrB8tZNjIAGPz4WTPPZ72VeinAmnIG3BFerUBV7TfY1mVjDwW9zahd+Z JlKBSuO1HiBPDgb2aYds/JsaMCxD12AbRNbiqPnPCBBg1QMyugmds9D0r0/8iD2Vx2Rf2JtTq l8Pd5nBPOlnGeV9RL5fehXsOc7FOe7jylcnoBxiKzIfqS+3pZT+IUw/B/V3xtBrEwNoYFSEuV VBJqvZ47ZL5+hy/XwkXPFzPyQe8LkcaFU+WhhCTglCl7i6Be5h+jMPMpCohRcd+RZ1fua76Oi i3QVALoTO1572rIhrVWvo8p40SNBtaFnvoHkMVOHj2E/Amr+egvcSbz2AE5WrjDIHV41x0llj erVoawDpOWw5C0P8bYzeMliENXACVTZXOyq5nchwt2h+tf6JuHdE6XpeFb0h9SeZIN7xhWinz kfUt3oVd5rn14aPx52wRI1a6+lDFmL+3cKIn8jPomyu7MT8sLSs3WTCrVccrOWTLoY/YpDWoF rXc2d6PexHw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Drew Adams writes: > 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. I agree. I'm in the middle of preparing a patch. While doing that, two questions arose: (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." 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. (2) The remove feature has a strange corner case. Normally the first found association is removed, 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. (progn (setq my-alist '((a . 1) (a . 1) (b . 2))) (setf (alist-get 'a my-alist nil 'remove) nil)) ;; my-alist ==> ((a . 1) (b . 2)) vs. (progn (setq my-alist '((a . 1) (b . 2))) (push (car my-alist) my-alist) ;; my-alist ==> (#1=(a . 1) #1# (b . 2)) (setf (alist-get 'a my-alist nil 'remove) nil)) ;; my-alist ==> ((b . 2)) This is because the code uses delq to delete a found cons, and delq removes all `eq' elements. Is it worth to document or change that? Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 11 10:52:42 2019 Received: (at 34708) by debbugs.gnu.org; 11 Mar 2019 14:52:42 +0000 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 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 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== 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 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 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 MIME-Version: 1.0 Message-ID: <3af3b645-84e0-4208-be48-810e8cd2cfa8@default> Date: Mon, 11 Mar 2019 07:52:31 -0700 (PDT) From: Drew Adams To: Michael Heerdegen Subject: RE: bug#34708: alist-get has unclear documentation 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> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 11 12:20:13 2019 Received: (at 34708) by debbugs.gnu.org; 11 Mar 2019 16:20:13 +0000 Received: from localhost ([127.0.0.1]:39398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3Nev-0004Oa-8d for submit@debbugs.gnu.org; Mon, 11 Mar 2019 12:20:13 -0400 Received: from mout.web.de ([212.227.17.12]:43171) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3Net-0004OL-Sa for 34708@debbugs.gnu.org; Mon, 11 Mar 2019 12:20:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1552321193; bh=xTEB9O715RbHRFt8gFVmM1aggT15+lONyK5nE7aC15k=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=PSgiHnpkkTEsDn9vr/hpM0/R7CtrRKq0h+/T4kljdmGmr6tIFHzotXxCoi/xBeFNS vLX9s7aIHMxNncOgsyrx1riXkpLAJ0ubGypoj9Ay0d1LTwWHSmju5cpJz62arFyOFJ ylTEEyhDGpQ8og8oDzfpEIDTocX9kwbVQI20kJzE= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LrJwm-1gvdrQ38KC-0137nl; Mon, 11 Mar 2019 17:19:52 +0100 From: Michael Heerdegen To: Drew Adams Subject: Re: bug#34708: alist-get has unclear documentation 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> Date: Mon, 11 Mar 2019 17:19:51 +0100 In-Reply-To: <3af3b645-84e0-4208-be48-810e8cd2cfa8@default> (Drew Adams's message of "Mon, 11 Mar 2019 07:52:31 -0700 (PDT)") Message-ID: <87wol5l6xk.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:I+i5/d8UWqNE3QJ8ezz5LA7vyhYXyN/gWJdD0v6Ou2jUFWxJlDZ eRUX26RH7OESh4/tWPzS1RcZNJ+R2jjmLDGQelsYjYFWfxaClUsO3ndnl1rV3y8kRyy0pSG WO33S+biZbxa0LhltK0ISsp24e8ZqY+CCgDv4Em95zZ81X9fHdMlGgzBrcX6y0CWFN/qXKr JREOELTaiurD8kCTPnbOA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:T6hVbC42VYk=:kA/HXUpqPSbM6SRpxeffYq 86gMXuzpneVs6v3p9hqPVWN0nUKm8RpfqJ8eUT4g6TELP87FM3YyWTPZCzwYe5MnO822lI7c8 NQE9KPujCMg6rtTjpqBiJqCxC5LjmphVLP6hyaCE+9DCsjvAhMz/kpNXShmAmtGfHiBMwtgO1 smy0p+QaGS7+3VcbWHcrEkE0xuyUaBzXJ9WVF5EaVy7JDDwIihWtGDWn/8nwdJCYna7J7AHds tNLaFIcVJMyTBcKh2vDx+WcxXzyu3VfBp4CtRjAkRgqib5wgsgzUwe38C3K7+mewWGtuchHis JE0eUJrlpFo3mi+Ilbqae3UmYEPT5VBGCcPtIZI9Pqf03QZoBRlZ65vlsBeF/jKyx2WAgu46s 0y0bq5lTALpLHRxUPjdrxRl/+F7pQ9GbsiqwFQ/GV9XEXTRwFGDckurvz8oQfVaE0SU78+Y5n 25Y1v8yhmuESL7xA7Sky1A5Kh4mjiMwVUvM/oKxMOMBfFisGxlswu18iE7On6ZgaiVysY+gaJ ZFgVGCmMst/Owvvtk59i2mEJ6OqDi//WM+ylCprAdSzwcwzR6Lxmg9EGqQqoHNATwQJUt2uqF 2EcqlCdQi+K84bjkxV77R0zsZNvEovt3tg/Auv9vrKXwIMqpd1qkA/YuqKrwyVVXt9TRzDeaN B6IxZ7S8FOfZp/R98ORVp4niwuY1sDIaPQHkfWQ75iQEZ3XLQUFo8QZ3kkXMw7v1F3yip5ZYV 9CvLEyPZ83V0nK2bYl1Ok225qK4sVW1wXnrM2jKGUFduz2mRii2hC+YlI1+hnyt7/b1RcD53V vvsdC8Vp2LPMoWEfd2wSm4RqiWnWWLMxXhHRYBng5JtslbfmTu4wgZvVuL4gkcZ0CsuMZz6XF wKpW106bI/cG2iExKYNBvMxPmtjn7vnGwuAkfupyelTF93ky6kaA2JKlG/95B10IC0qfXfoWb iKYgw1napRA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Drew Adams writes: > > (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." > > > > I wonder if there are use cases where the user wants something differe= nt > > than `eql'? E.g. `equal' when the associations are strings? Note tha= t > > 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? If we do that, I guess I would rather allow that the non-nil value of REMOVE is allowed to be a function. A related use case would be to allow to delete the association of a key independently from associated value. > > (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. > 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. We tried. I think the result should be consistent and convenient, but we don't need to implement all realizations of all operations for the generalized variable. 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. > 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. Yes, this is what my patch will try to accomplish. Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 11 13:48:30 2019 Received: (at 34708) by debbugs.gnu.org; 11 Mar 2019 17:48:30 +0000 Received: from localhost ([127.0.0.1]:39452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3P2L-0006WV-NM for submit@debbugs.gnu.org; Mon, 11 Mar 2019 13:48:30 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:52620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3P2K-0006WI-3b for 34708@debbugs.gnu.org; Mon, 11 Mar 2019 13:48:28 -0400 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 x2BHhcsq153142; Mon, 11 Mar 2019 17:48:21 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=3WZnMijpXpWrAP/ASkoRFZ+HtmgAxXCoRm7SMI+RbJA=; b=1C+RGcm4KzbJviixU5ZeqTqF7Cg9fFfEqnTfKt/RqMn5fLo+RmVgDbFApAG4ATK3xa7s xuhZcVe/1d5aheB0Qs/Y1LGP7EQPmFaXARrM6sid9ui2YEumoSRkI4mO8VGdRTj2Vx+x f2+aHn8aMdW2xYzIbbMXCH17H4gHWikSIeE6eR803epyU8K1HaZ/HozhNI8p2Cz4xOvd XU7fxDIMynbEfgxqcCvsTwIWMU5pxqqSHyZ7AzLQs+rTXw8qKCjwbLWXO8UHmJH+3a4D 15a7hgd6HeTT0YARWzzIhwbwZec4LZt3cSztS+YcOl6QTgfX1YFkRITIoeb0S5EZLu3T HQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2r464r7xsx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Mar 2019 17:48:21 +0000 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 x2BHmLjI017731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Mar 2019 17:48:21 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x2BHmHGW030437; Mon, 11 Mar 2019 17:48:17 GMT MIME-Version: 1.0 Message-ID: <6e0c5a88-34db-4957-9cc5-98a14ae64f9f@default> Date: Mon, 11 Mar 2019 10:48:16 -0700 (PDT) From: Drew Adams To: Michael Heerdegen Subject: RE: bug#34708: alist-get has unclear documentation 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> In-Reply-To: <87wol5l6xk.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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-1903110127 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > > (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." > > > > > > I wonder if there are use cases where the user wants something differ= ent > > > than `eql'? E.g. `equal' when the associations are strings? Note th= at > > > this is something different than TESTFN which is for comparing keys. > > > > I think so, yes. Why wouldn't we want to allow that? >=20 > To not add one more argument? An _optional_ arg. Why wouldn't we want it? 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)'. 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? > If we do that, I guess I would rather allow that the non-nil value of > REMOVE is allowed to be a function. A related use case would be to > allow to delete the association of a key independently from associated > value. That'd be OK. If the second test function would be only for removal then letting REMOVE be a function would be fine. Presumably it would be a predicate, testing each full entry (the cons that holds both key and value), not just the value. > > > (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? >=20 > 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. 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'? I may be missing something. I'm not familiar with the whole bug thread and I'm looking at the existing (old) doc string. > > 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. >=20 > We tried. I think the result should be consistent and convenient, but > we don't need to implement all realizations of all operations for the > generalized variable. Then isn't it a bit misleading for the function name and doc to suggest that this is a general way of using alists? There is already some misunderstanding out there about alists, with some folks thinking that there should only ever be a single entry with a given key (which is true of a hash table). Won't this augment such confusion? 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. > One thing I don't find consistent is the case where the alist already > has multiple occurrences of a key. E.g. >=20 > (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)) >=20 > (alist-get 'a my-alist 1) > =3D=3D> -1 (!) >=20 > 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? But if you don't find it inconsistent then that's a problem, because many (most, I expect) uses of alists do have some multiple occurrences of a key. In any case, what you show is an example of why I wouldn't think that `setf' with `alist-get' is simpler. It may be less verbose sometimes, but it doesn't seem as clear. If, as the doc says, it removes only the entries with a given key AND a given value, then isn't this: (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)? Or if, as I think you're saying, it removes all the entries with a given key, regardless of the values, then just this: (setq my-alist (cl-delete-if (lambda (entry) (eql (car entry 'a))) my-alist)) I find the `setf' with `remove' and double 1's to be confusing. It looks like it removes all entries for key `a' that have value 1, and then it _creates_ an entry (a . 1). I know that it doesn't do that, but to me that's what it looks like it's saying. If there really is a good use case for `alist-get' to be a generalized variable, and for that to let you remove entries and not just set/create entries, then it seems like a better syntax could be found. FWIW, to me the whole remove thing seems to fly in the face of what `alist-get' and `setf' are about. With REMOVE `setf' is NOT setting an alist element. Instead, it's changing the alist structure - it's not acting on elements of the list. `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? > > 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. >=20 > Yes, this is what my patch will try to accomplish. Great. Thx. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 12 09:05:15 2019 Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 13:05:15 +0000 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 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 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 From: Michael Heerdegen To: Drew Adams Subject: Re: bug#34708: alist-get has unclear documentation 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> Date: Tue, 12 Mar 2019 14:04:15 +0100 In-Reply-To: <6e0c5a88-34db-4957-9cc5-98a14ae64f9f@default> (Drew Adams's message of "Mon, 11 Mar 2019 10:48:16 -0700 (PDT)") Message-ID: <87ef7c1bxs.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:mkr5/hwYO0DenZyCtFLzxCiifQmCIKeGkp5viDd2QXXErzd0GWJ vQvmlYGqY9ZjdVrijNam2TV7JPuP42aTCtg9O50a0xLCdp0lA2riCwq43UIDRbV2uSTjMsM ilacnx1zRnCOaxhKmZktpGhFm6CHf07QdMVK3Qu7kcV9zvLoQEbGU77IgT7bjU+16ENo/Kh 6XEaqZSLE9E+GrIwHEVgA== X-Spam-Flag: NO 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/ipQhsNMpiGg8X3nM D/29RattMl4vMMavvnrph5iFvTyQtuqEr1yzuKu3CTlljQG8w++gOmm7qeQICbQzN2o9OUpXC Hy+8cN4cS/M4nfsJUqvJ+TwUbNj+427mHdbOEZ0JL2wG2J7fezXSXOgHCscjb6uMYpPweKPHJ I1618Vohpnw== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 12 09:12:55 2019 Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 13:12:55 +0000 Received: from localhost ([127.0.0.1]:39847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3hDD-0005kU-In for submit@debbugs.gnu.org; Tue, 12 Mar 2019 09:12:55 -0400 Received: from mout.web.de ([212.227.17.11]:43941) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3hD9-0005kB-Vj for 34708@debbugs.gnu.org; Tue, 12 Mar 2019 09:12:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1552396353; bh=u/aMudwJ3MLHFK15Qsfj08JJ0Kk+RIUkgsO+oiJ1qh0=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=ZuzLRS3IZgwd0maU0xFEzosXM9HKZqDb17PdP5btNR268vJrdI1EPR95atjh0yAfu qJtzQhoJzlYHkdTxUncezASaZc0O8awAHpgtHUToHvUxzXkV0/0T2aJlEsnW0bPFcz tWahMghwaa2h3KkfdpjrWAx8WeycpUGVRs4bPR3Y= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MHp8z-1h4XDo0lsz-003cpq; Tue, 12 Mar 2019 14:12:33 +0100 From: Michael Heerdegen To: Drew Adams Subject: Re: bug#34708: alist-get has unclear documentation 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> Date: Tue, 12 Mar 2019 14:12:31 +0100 In-Reply-To: <3af3b645-84e0-4208-be48-810e8cd2cfa8@default> (Drew Adams's message of "Mon, 11 Mar 2019 07:52:31 -0700 (PDT)") Message-ID: <87a7i01bk0.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:jVbHMivigFhP4fjhUxiPKtekbLwIL8VLyBlmwU4zPw2MLKupa8O bt7tNU2zTRNbYzll6ODOzsUBOrY7qyi9kUegR1n4pLRIhtodap7763KdzziBDWUULVme6XX 3ulzN0+ujaMp+R6DAboE3PP2ZAh2lbxuyTuVIVWjOYzSgQxYwCcODzGFpf66SJB2l+rYf8H 85bIzrd7PB9YkfmE9hbNA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:+xd6eszIExs=:FSka/I4cGwJnD0DxShyfVb UFyF2suBCS9gCTyEt6GitChjz2SheWHFU9wD4oJI2t+zIHp7vc/AKYcOdg8WXyg2o+hc9wXfX Tsfneu8BD+0M0vesuQhhTZlh1MGJ4cwqQYxDFDQlk4LU8Pf2rA6LHY6AHCKZ1SWMrEBsyzu09 BLVwMj355MY45cpXio0oKN3TmdlQ870CCLmjReCFLNnX18CtllyQPSiv8tAYpGy2difssJ4Oj 2PM5VlyNAs25RJ/X1rSc9oWDL6KCZey1zTiolTND8JlWaiv6H4A3w2hsjwTxQfqywELxDoo5s RpydSF46kuIjuT3sr8E96lYsICTW14OWF6Z6wj3xQbwP3yL4uIaQgnbCq1KHulXI43md1EUb5 xSLmY9GaZfYLE5EBMmW/KLhRw3MBagpm9ps8UjWourx1eKXivOJR0REe6hEbbTvkSgmTI2JIS 49Q5BWAA4KRa9hqeFUeyu52aUyaIYrVmyeTuODejBEVj8DoLjBnYIni6Thid2/EQbSKvafMuv 4sOhyTzSWemvAPpHH/VVhD891OryoiduOyLM9bFsduQ7hghNVOB2lgMKo3tprteUPqwriFyqH ZP9+v5yLkkGomhb9ayR6/2l74XOBTU0rv3N2O7H0qAw1SPusKmp10rvMtG6WgQQaTSdRPiz/m oJKWvxuHKLHJrbnTNJQfGnpguHrw/f40B8dYIIhrx5InePRZdElLXA+CpLPCQPaaTXDSOcL1P 5fAqAMBWZ5fWKfpjcrHnVsQYtbO74lTIzSXKdn7OGmZSet295aiJoN9nmizx9w12/ITN+kuJe 9CfvC7bh9q+iKpjEVRaH7bLsvm1jBcL7A3kremi1i/0C0+L8Tx4cpKXAufNYWsOjzYDW++mvH nu21lCtn+Kp78nut3WIa1zxRkeWo4MvhAfl35piezOLJ28FuyxF/TGaS1Ewl4OnJtDFKezL8N rAmDD2hjlvw== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Drew Adams writes: > > (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)) > > > > This is because the code uses delq to delete a found cons, and delq > > removes all `eq' elements. > > > > 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. BTW with a different viewpoint, when you use (setcdr (assoc 'a my-alist) 17) on the above degenerated alist you also change _both_ of the 'a associations, so one could argue that the `alist-get' setter behaves correctly when removing both: there are not two 'a associations in MY-ALIST but the same one has just been added two times, so it's correct to remove both of them. Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 12 10:48:38 2019 Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 14:48:38 +0000 Received: from localhost ([127.0.0.1]:40420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3ihq-0001xi-3J for submit@debbugs.gnu.org; Tue, 12 Mar 2019 10:48:38 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:45066) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3iho-0001xU-6X for 34708@debbugs.gnu.org; Tue, 12 Mar 2019 10:48:36 -0400 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 x2CEhxlB171164; Tue, 12 Mar 2019 14:48:30 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=RGdE8A51a4PymeodG1gSwY1YeO6x+7zerKBHEv3CQs4=; b=ObEwGlJlRGRqBjTXRDwq29lQlNCtLlxMm9Tdf0SmJqwfHZ5QQR/KM6AS927ZWkuU8cjX D88pQY6W0ftHVjI97mdOzg5wRtymK+7lPikZlUx2G1s7PMG9GgvcHbzjeulbx0PsHFNg bKgIj6j1M2c/Vm0B9Xtb7UIda6/10a8MZrwkovRz7Dg1P6hL9aCtnGS79l8PNNTh4tSZ hAoA9JooD5XLwJRpWzWAO2Eg/8vAXyChcETSpqYWT0CnINwNOgEhGasowcX8KmfRPOpi i8G9kQxcqn2G+qIT3oz9uMkjiWZjNnpwi0CcbmPd/yXjkVtzO+8nEBf9NpgKsTY+KLaB 4w== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2r44wu54mr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Mar 2019 14:48:29 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x2CEmSxJ026355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Mar 2019 14:48:29 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x2CEmSQd029289; Tue, 12 Mar 2019 14:48:28 GMT MIME-Version: 1.0 Message-ID: <32eea01e-cec1-42b7-8221-f4dd4652f0fa@default> Date: Tue, 12 Mar 2019 07:48:27 -0700 (PDT) From: Drew Adams To: Michael Heerdegen Subject: RE: bug#34708: alist-get has unclear documentation 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> In-Reply-To: <87ef7c1bxs.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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-1903120104 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > 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? >=20 > 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. And even for the elements of an alist I expect that is more typical: a list of values (as VALUE of a KEY) is more general and typically more useful than a single, atomic value. If this is the case then it's an argument for the default being set to `equal', not `eql'. > > > > > (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. >=20 > It removes the first entry with given KEY and value eql DEFAULT. [FYI: "The first such", above, meant the first entry with a given key - "such" refers to "entries with a given key". It doesn't mean the first entry with a given key and value. I guess I should have made that more explicit.] 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'). 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? I'm still having trouble grasping the point of having REMOVE in this construct. Seems like a ball of confusion and behavior not specifically related to alists. > > 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'? >=20 > You can also cl-delete-if, yes, there semantics overlap. OTOH > cl-delete-if doesn't support generalized variables. At any rate, that example was predicated on my wrong guess that REMOVE removes all, not just the first, identified instance, which you've now clarified is not the case. > > Then isn't it a bit misleading for the function name > > and doc to suggest that this is a general way of using > > alists? >=20 > 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. I find it misleading, but people can see things differently. Getting an association by both key and value is _not_ the general way of getting an alist association. Getting it by key only is the usual way. Getting it by value only is another, less common way. `alist-get' by itself seems to act normally wrt alists. But its use with `setf' and REMOVE doesn't seem, to me, to reflect the usual alist manipulation. =20 > > 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. >=20 > 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? How does that change things? Could you give an example that shows what you mean? > 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. OK. An example would still help. The `setf' examples we've seen so far don't seem very helpful, to me. But maybe an example with some other `*f' place-manipulation functions would help understanding. I think it's mostly REMOVE that bothers me. I expect an alist "place" operation to set (create or update) an alist entry, not to remove an entry, and especially not by specifying that entry by both key and value. > > > 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? >=20 > 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. You have _not_ set the place to 1, have you? The second 1, combined with REMOVE, doesn't set the place at all, does it? Doesn't REMOVE just remove the place altogether? I think that the REMOVE "feature" gets in the way of understanding here. I think you're agreeing, in a sense, by saying that the sexp gives the _impression_ that it sets the place to 1 without actually doing so. No? > > `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? >=20 > 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. Let's consider just REMOVE then. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 12 10:53:24 2019 Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 14:53:24 +0000 Received: from localhost ([127.0.0.1]:40425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3imQ-00025C-VC for submit@debbugs.gnu.org; Tue, 12 Mar 2019 10:53:24 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:51500) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3imP-00024z-AW for 34708@debbugs.gnu.org; Tue, 12 Mar 2019 10:53:21 -0400 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 x2CEq6q6180299; Tue, 12 Mar 2019 14:53:15 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=NSUqAwfcaFrI+GqQCo1iJM9y3KmjwmhNL6Hdh6aN6/8=; b=caHF7kfUWQ6uNKl/E9TyXGKJng1wbZ/ap0U4bydfrtd5R5j9NrdGIWjSmnispZssePdW kA0ZYF/ViNuzGuOF3/ITV2yfzb0ldRg+N0OKjbxvFGv3DgimajymH46mhhs3gmFih9a1 gD0YiSdwwOFVknyVzbW9xAEZOjYl+6J5L/cHkM1IeghbhkyEregmhxx904bEf098Tzd4 SZy93sPwo/InUnFyZlbbjiREsTJW9mbaWf2/8O+DUVUJO31ydtozVEwT5p8kQUG4GbKd hHesMybHPr4e0Rx+bNiEBG+OrPK9+TcOh0uaET9RBP2xvWtiEqKUj3FAURsbXmEBP153 9g== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2r44wu55ny-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Mar 2019 14:53:15 +0000 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 x2CErFoI024502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Mar 2019 14:53:15 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x2CErEIA029069; Tue, 12 Mar 2019 14:53:14 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 12 Mar 2019 07:53:13 -0700 (PDT) From: Drew Adams To: Michael Heerdegen Subject: RE: bug#34708: alist-get has unclear documentation 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> <87a7i01bk0.fsf@web.de> In-Reply-To: <87a7i01bk0.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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=970 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903120105 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > > (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)) > > > > > > This is because the code uses delq to delete a found cons, and delq > > > removes all `eq' elements. > > > > > > 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. >=20 > BTW with a different viewpoint, when you use > (setcdr (assoc 'a my-alist) 17) >=20 > on the above degenerated alist you also change _both_ of the 'a > associations, so one could argue that the `alist-get' setter behaves > correctly when removing both: there are not two 'a associations in > MY-ALIST but the same one has just been added two times, so it's correct > to remove both of them. OK. Put it differently: it's worth documenting that updating an alist entry with `setf' is a "destructive" operation: it can change list structure. Dunno whether that is already said somewhere, but even if it is, a reminder wouldn't hurt. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 12 11:40:34 2019 Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 15:40:34 +0000 Received: from localhost ([127.0.0.1]:40454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3jW6-0003Fs-BM for submit@debbugs.gnu.org; Tue, 12 Mar 2019 11:40:34 -0400 Received: from mout.web.de ([212.227.17.11]:33799) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3jW4-0003Fg-VC for 34708@debbugs.gnu.org; Tue, 12 Mar 2019 11:40:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1552405127; bh=aaCp2edLttpkGLzC6yUhemWDuLvvRZXuESRpTqdCkaQ=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=RkkNNCCJLtbF+TZaU5Easi9N2gRVj7sU8IQxcngGlnk6M06T+KC6XH1pZlyYwPTki naKJX/kYeiWkJWh2wxrgHVLMJMiRN7VrBj6N8YVWCg6jAezn7jF3L+Rw7d3v9fK12Q LQSV1dKWODR0wWjK6ffj4raQgzmK0RlOqfH04dp8= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LkPrz-1gVmNo18xf-00cRpf; Tue, 12 Mar 2019 16:38:47 +0100 From: Michael Heerdegen To: Drew Adams Subject: Re: bug#34708: alist-get has unclear documentation 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> <87a7i01bk0.fsf@web.de> Date: Tue, 12 Mar 2019 16:38:46 +0100 In-Reply-To: (Drew Adams's message of "Tue, 12 Mar 2019 07:53:13 -0700 (PDT)") Message-ID: <871s3c14s9.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:KpU2r5Mpsn2jPzuKIDnA3s5oR+NNddGpAXEO8NUYwBNn2JbtLIq D1IOHXBS13MGBClUwnutTVmoB3Z+e3pSGsenfh+U+tPffUXczG+396J6s9sVlGcfgrudD8k ZyMhOw9sPAReWhmGHtUxvcDy8yclMP5gaTnVHv2Q5LXGDlnF4P8lz8OqACq+d1MLFrsf4UM b2IivGcVhwfBXcvebr4Pw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:FYb5oqMMxk8=:1EIDLjjHBx8nEgHoimAj3f nNTayWqRCyHNiJuraWP5YIKmqp3diS5+QjBu5EJe03KJEusyPiz40QQ0SmHbK1is+GAOhj2zD bVtB2PCMDkCbDl65ps0mSIVd37c5zix0j+3XZsDNo3fdKRgFjAaXg00EbBG5YY9RZiNX03UGY 6s//ms1nf/H1THh9eFQ9Spj5neuW3WK4b0YsjdBdp585ghc3AHdeNFOzlilkn+Cv8wY+cqkFI Qk8a1d7WqZffJ5woLJrXURlSoBdcnUo/MLewiFEom1wrwXfwyFQmbPE32Vv041qffGPRP+y0X ZXcyJkgmQFWRXR5Th9pC01ooUH6nVaKg/xu/2KZ4YujOmwnGcuPjy1TyjLeDk26KyPtenLYaQ U/YXC2BW+z7SI+o/z4E/4Wa6RXBEprvKEVix/1LVRG8EnOpTzBPNPki1gaIF1KxkhIalK3VSj GkGQr0E96RAL09reZL1dcx9Hpo37mX5YNtDPzsEPw50FON6kYox2eiiDu4DXSgZny6kb6Ct+e nDfAqIqpQ57XnciN84rRH05jm53eaozgpbpixamypCw4C2Pi1EPATnonuNmmx6fIBD+6y1eBD QcVwRjua+lSv/jQuj36S6KvatJ/hbd/iRrxprg0kAIVc7lsG4Shr6KMyNY/OvaGUOy4rGYgjY uGj5RG1nPZt5C2788iSzpeSWrANMrApPmBTVI4uoSf75LNe0bf9+hYNW7KuwYgma1kXvf7PEz ybYoRIaTq02bvywxJdn4fLhouQQ1FWQEbqaz84K6cFAUYkPhAx6Jzri7w1CaN1ZI7jjIbdnvc 445s7zYabBXYj9txIDGKql0WDCAIUlP7KVFM9QRyj+KdRtKKYgJhHSRgDWsYgMV5OjqmVTspl UBQh1jsavmSJHKSVw3C9Y6b1m04Ugwm86xhS4yYlBJN9l6bseW8qUtWdCi2zk+uvNeQLbUOFU 5Sbxpf134bA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Drew Adams writes: > OK. Put it differently: it's worth documenting that updating an alist > entry with `setf' is a "destructive" operation: it can change list > structure. Dunno whether that is already said somewhere, but even if > it is, a reminder wouldn't hurt. But isn't that trivial? How else could we add associations? Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 12 12:09:21 2019 Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 16:09:21 +0000 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 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 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 From: Michael Heerdegen To: Drew Adams Subject: Re: bug#34708: alist-get has unclear documentation 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> Date: Tue, 12 Mar 2019 17:08:58 +0100 In-Reply-To: <32eea01e-cec1-42b7-8221-f4dd4652f0fa@default> (Drew Adams's message of "Tue, 12 Mar 2019 07:48:27 -0700 (PDT)") Message-ID: <87va0oyt0l.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:Vp2N6GjT4EZYK1DzuV48fBkmlIx7Hya2veEARP+0ToJyK/CsWV0 OhLc47yThMLYr3LMpsInN2b/atci83qwd1w6n9tiwo9XLn4T7w+tyy7e08lE5v+EqrfZuR6 f14pv7sJQBAfx93JuKdOCfGCABMk+8q3E6/oF3eFH41iFszWJYeBrpqFftVgnR/J/aZ7ihk EpGKjpu5osS3dspymxOoA== X-Spam-Flag: NO 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/whY2piYkWtF8lHMttbq9CxqaPz7a0NKknoPSBfSJBZGSBJ5MCP2N3 WWGPotEnTxxSuuiSbDHPf93/+lBgr6PKDEr788MPJndhzKwUurYWbqXyf7K9inu9w7Tbr3uzD SzA/9E8eab8UiZ4yGh7JhO7TCFaQ9AKwaUQJ+ULnmKDGK2LBzD/pl/DKN+pHc7s5TmG0nKTOP 3aFtWTsj05g== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 12 12:18:39 2019 Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 16:18:39 +0000 Received: from localhost ([127.0.0.1]:40494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3k6w-0004DJ-NR for submit@debbugs.gnu.org; Tue, 12 Mar 2019 12:18:38 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:44082) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3k6u-0004D6-Ng for 34708@debbugs.gnu.org; Tue, 12 Mar 2019 12:18:37 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2CGDfOS102389; Tue, 12 Mar 2019 16:18:30 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=N6Cv3IN1cGwtLDFKct+X8ItrlRj03Re4Ic8BXSwDtdo=; b=NhdiTma/M57M7pIa1yCg/6wsKFOjt8p3dyNNWJIqA/fHsACDu0Ar1psQ3JHO8qAoE4Ha 9gh0H73OXyeQ9Q422SrItjyGEFgmGVN4CpbYVxEc9VBoJOZI3fg6LPdjLIgpyai1H+W8 1eAlGlltb4v7rfIBsOZkoQqkeCkkxb9/Ku/5BM4KWNZDelDhPAnp0xKMRIhkFyZdFV5q wEF84oxvtWt25eVcWF/buhfChWH7rwfbxr4utHnWTEt4DsboRoRy+EtzG9ioh8x4eps9 q17pTJ8qwFB/uMecNyh9pLG1jyGLBo7hC6S3N9KueS8iZmSMPK3FE4iXQdfwTI+CMYq4 2w== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2r430ep8f2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Mar 2019 16:18:30 +0000 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 x2CGITTp027853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Mar 2019 16:18:29 GMT 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 x2CGISqc021726; Tue, 12 Mar 2019 16:18:28 GMT MIME-Version: 1.0 Message-ID: <5fac8365-68d2-4cc5-b5c3-d2658350ea28@default> Date: Tue, 12 Mar 2019 09:18:27 -0700 (PDT) From: Drew Adams To: Michael Heerdegen Subject: RE: bug#34708: alist-get has unclear documentation 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> <87a7i01bk0.fsf@web.de> <871s3c14s9.fsf@web.de> In-Reply-To: <871s3c14s9.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903120113 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > OK. Put it differently: it's worth documenting that updating an alist > > entry with `setf' is a "destructive" operation: it can change list > > structure. Dunno whether that is already said somewhere, but even if > > it is, a reminder wouldn't hurt. >=20 > But isn't that trivial? How else could we add associations? Yes, it's true of `setf' in general. It's still worth repeating, I think (just one opinion). One person's "trivial" is another's "gotcha". But apparently we don't even point this out in the Elisp manual doc for `setf', alas. And even for `setcdr' etc., the manual doesn't repeat it. It mentions it only in the parent node, `Modifying Existing List Structure'. `setf' is not mentioned in that node, BTW. Perhaps some mention would make sense, saying that when the place to be modified is a list the list structure can be modified - it is a so-called "destructive" operation. "Destructive" is mentioned in node `Rearrangement', however. Why it's not mentioned in nodes `Setcar' and `Setcdr' I don't know. (Sure, those nodes do make clear that list structure can be modified. But they don't specifically call them "destructive" operations.) I suggest we document explicitly for `alist-get' that using it as a generalized variable is a "destructive" operation - in both the doc string and node `Association Lists'. Whenever we say of some function that it "is a generalized variable suitable for use with `setf'", I think we should add that using it to modify a list is a "destructive" operation, i.e., it can change list structure. We should be a bit more consistent. We say `delq' is a "destructive" operation, but we don't say that explicitly about `delete' with a list (node `Sets and Lists'). (We do say it indirectly.) I'm not crazy about the term "destructive" for changes to list structure, BTW. But that's the term Emacs Lisp doc has chosen to use. As such, we should call it out everywhere it's applicable - or nowhere. It is not the case, for example, that `setcdr' is more "destructive" than `setf' + `alist-get'. Some get so excited about such "destruction" that they make a big deal about strongly discouraging users from using such functions. I don't. But I do think it's worth explicitly making users aware of which functions can change list structure (as well as what that means - the consequences). From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 12 12:48:23 2019 Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 16:48:23 +0000 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 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 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== 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 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 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 MIME-Version: 1.0 Message-ID: <84e7fa6d-7e89-4c7e-b94d-be40900a3422@default> Date: Tue, 12 Mar 2019 09:48:11 -0700 (PDT) From: Drew Adams To: Michael Heerdegen Subject: RE: bug#34708: alist-get has unclear documentation 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> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 12 13:46:04 2019 Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 17:46:04 +0000 Received: from localhost ([127.0.0.1]:40552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3lTY-0006Kx-JX for submit@debbugs.gnu.org; Tue, 12 Mar 2019 13:46:04 -0400 Received: from mout.web.de ([212.227.15.4]:51151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3lTW-0006KD-QA for 34708@debbugs.gnu.org; Tue, 12 Mar 2019 13:46:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1552412741; bh=6nOPEHsQ8AK/rCFHZsC3IPFvUCpU/ucNy8m1IuVMENU=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=djczxP9PF09NIHLJ28FMSPazeR4vZLjkSysm+75R1in5BwfBIITT7RfnRDK8dk2ju Ku4590eCVviY+zK/xyc4Bd5Qzsomso9jRdhz9PAlSH0G9Ik+9cRo4r54MtsRPoetM0 g5HuuyC9UuyG1Nteqnmpy6r/TZ5q3QV7ayR9x0HY= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb003 [213.165.67.108]) with ESMTPSA (Nemesis) id 0MfYoV-1hR41O0xIJ-00P1Ud; Tue, 12 Mar 2019 18:45:41 +0100 From: Michael Heerdegen To: Drew Adams Subject: Re: bug#34708: alist-get has unclear documentation References: <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> <84e7fa6d-7e89-4c7e-b94d-be40900a3422@default> Date: Tue, 12 Mar 2019 18:45:40 +0100 In-Reply-To: <84e7fa6d-7e89-4c7e-b94d-be40900a3422@default> (Drew Adams's message of "Tue, 12 Mar 2019 09:48:11 -0700 (PDT)") Message-ID: <87mum0yojf.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:y+Dyr0NXIjSBwuVUUulzWItfv71oZN+/R6lyublAfv9Dj4rop9Q 2RSAKkcagA/67q49akBin3q1PBz2xsgof4qjpv85ZJ0r6ljA22b9q5AzQiCRhoNeDCmmnnk W3TPGjQa4DRPu9UjHiNIMuMRo97mtcqnAUe8h5x+X+XQy44ABjqv/USKfQ47VxHgKrVEN5B 70dFVpciHlg9cBAZ0xhwA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Aj4VrHXhIKo=:6TXIUruh0bwb8NGuqv8Txq 6ZzL2hkLBfNQpV4oThN3+yW8iTGgkvjOrzvYKhf59KQziFxq0RqHv/eYWjHZk/yBSvjtaI9ol 076t/hS2TAUE7clVqu0LtmaAJGoG+a6fwCGHSue2Y0FlgAMVMt+H0/vcdDWw+cqglGjGq9dKU iIs3S6IKAq1t0P3/UHVFj4ttIiTUbcCaFM4HnhtMY3sToVDTYzo+BTM3LGhMbEabr5r1iTjXF zclCwjktWlMrEaxzWQffF/nusYVwTw7kunAaem3emfjwz+Xhi1k6k4m1aFCgJXqBhhiRGTCZI 0w2rNDQI94m2Y8LKICE/0xG+EVw36G5yModihbaBU70YzzNEp6LwvoJs8v06KMLrfzXZP+XAD FVQuP7XeH3oy6B5CU4mD+j9WJUTvw0o83sJsDJBlEDysIlJ8wCQJLpfyqjYPvkSnuDQJCXKO7 /JNt1DQ9ifShGRpnURSwGY8bjLAVZm9S/6y3kMvjx8uu7i59AkDjqGbuMcQnZPWU5uGVixzXV FLp2CIabCHAXxYrREddHKT7f3tr3uQbn0BS/gpNRYdAICdS2hKeoVM25uWcjHtttiJoK/DG8T TSvjYlJX7F3jKuFDXnixbtA+LPsR3cIMaNcXNDw9aD6VDoqxNATI7zL8Bck2KKQrBWjDXsVQl 2Qtn29iWXW+dSgT5TliW7wiz/iRh3r3LXfhzelt1yANZHnw1nwfD0714XlHAS3BZOANND+MlY p6JQTnDUQonbu7py61YMTPR7PAZi36IKqHE6W/NIp+9TwITlZt+gS6Ur6yQa70XKCCU5tYFwc fIL/4zLfFesXCT9yZettT9ePrfknmAWiLaPYUFcsrH3rdJYKXGVTJJsquH+U/PcZVjxqOH4mr 7/Oa41ReTHB3eNqUaxg+5/divHH6z/TbI2xLEGSlK+cHra83COdqJesg55NOIbwVkTEaCC6ba 7p2OQUOYWvw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Drew Adams writes: > Why have REMOVE instead of just letting users > set the value (explicitly) to DEFAULT? That's the default behavior without using REMOVE. Removing associations is also a valid use case and in my eyes still consistent with the place semantics. > 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? Ok, REMOVE is more or less your only criticism. I too find it a bit odd, especially the additional argument, but not too odd and useful enough to keep it. It's very debatable, agreed. Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 12 13:56:11 2019 Received: (at 34708) by debbugs.gnu.org; 12 Mar 2019 17:56:11 +0000 Received: from localhost ([127.0.0.1]:40556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3ldL-0006ZW-Hx for submit@debbugs.gnu.org; Tue, 12 Mar 2019 13:56:11 -0400 Received: from mout.web.de ([212.227.15.4]:38245) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3ldK-0006ZK-8b for 34708@debbugs.gnu.org; Tue, 12 Mar 2019 13:56:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1552413357; bh=WC8FA9Mgr3VV95T1w9EQ2+e5W+bpf2pvQNEW8+Nv4uQ=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=MkPX+MD2jk+RURicZRGeyJN0ftc6OFsiKgm4xIkNyyEY8FJ060t1IAREaa9yJDzyB enXbLXkfv448Blh6ji0d6Ed8l+ZXASliSsEYw3fXfBbT7dTOosu6OnDt0jM5C80UI0 smV05YAOaEaTcBVwjcPcICX1YHyTKtd5YDpC5D7g= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb004 [213.165.67.108]) with ESMTPSA (Nemesis) id 0Lj88M-1gUzZb2ov8-00dFiN; Tue, 12 Mar 2019 18:55:57 +0100 From: Michael Heerdegen To: Drew Adams Subject: Re: bug#34708: alist-get has unclear documentation 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> <87a7i01bk0.fsf@web.de> <871s3c14s9.fsf@web.de> <5fac8365-68d2-4cc5-b5c3-d2658350ea28@default> Date: Tue, 12 Mar 2019 18:55:56 +0100 In-Reply-To: <5fac8365-68d2-4cc5-b5c3-d2658350ea28@default> (Drew Adams's message of "Tue, 12 Mar 2019 09:18:27 -0700 (PDT)") Message-ID: <87imwoyo2b.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:AeTJ95KxukMgNA1Y0vujtOhVBolCe2/6lrw2Qhn2PmgdfkYEEbV rVvslEp9D/RunnazqGLHNywgThCG2L1iJ2ibd39tTBE3R/08zBlKWYT/jkvSaHHOwArN6EU s547zkuWvBfdJRTB1x7rE/ZdRh05TJMUFZ4ijDlSCaXswd6WK9AxIJgSI8s3fuq5MoLKDiC GRA+8koO/ptrekTRrk7vQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:oj/2n3kP02w=:MCS6uGu4IeYC0+lUl67aTy WideowADxbLPUkS3QOXoUHbfs8ge3/9hgpBHkb5sLeTRba8WJJtcmQ06MsQu9g/jmHaFlWxvM h+yCZ6ntJ/m/FW7MxzHe7lx92pUzEOmDAJ6DxLKQzk3dOe0Kn+H9YWeUyDorX6wBBTb5k5Qd7 6bN3PXpx5N0cwgHHQPSxwUs8ZCmW0MVb0l2tnwnEdXGUwL8Es/J0hney3knF+eta3sPt26Z5X iyf7ayOzrZFNAtpkZLFGOdT0lNmE2T+Gf98uOUpL9RbRwlVf6KSsTOUA46Q/Oovkl+NJC9KzV VgCjSeBko8Zu/AddHP8Td/2EpOBjBwZepEiNywhvy8DzXQzbq6279USiy72VdFe6QTKevEq0q Z7gGnPwiWAgZYBv91TrhjDmpUT2+dVySyqbj6AvnDYjOwvpUYmGpJxBjdSu9wK1bIFFj9DGsq B2fKasAgyZ2Pbc9lGs8fT2va6EBoLfs/tNa3YOB2qugPJCtOj8DXX+kkimjjfZu/teJQY61nq FtbPlPvi6zfErK2iRv0BhGgyYtUiGewyjhNUO2n2N1+zKUwt10pvdNJsNeq9SMgDeUIdl8JHA 9Znukf/3iFDaXfqnaTDNYoNCSM3JVz84JKBfvM3ddAJaW4N6sxoEUGE0KAhn5irDPJJoV+LUu 0A6IFd2ebab+lS0B9tE6JYpGNJiMr/+fRhqYBPiPPeiPVhyLRdSvCXGLBPfv6IjB/WVLqOby0 2A3rCVpVe2NZLA5LnutG3eSjBi1aouMFueeK+DR45q+ZvLQu2shlW3H+EadR6ICRRKpcMYp7R Tk3WGZiRfW3fxYerPf4tqtz9EZOnhf6tHb7gL1uwu2Xy0zlfNnmEbLftVM+yZhsROobTbEssJ CEdvdaFUBQL1tVy1dddrWR1pAMzJDqKhXF4BolEOCm3XrOwAVzkfl0V4uuG9L7nB1hP8BCfKZ eP9zHtVHnPw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Drew Adams writes: > > But isn't that trivial? How else could we add associations? > > Yes, it's true of `setf' in general. It's still worth repeating, I > think (just one opinion). One person's "trivial" is another's > "gotcha". Actually, it's not even trivial at all. Setting alist-get as place could also build a new alist, leaving the one stored in the ALIST place intact, and set place ALIST to the new list. But it potentially modifies the list stored in place ALIST. That's not inevitable, so it could be worth telling that. Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 15 11:55:12 2019 Received: (at 34708) by debbugs.gnu.org; 15 Mar 2019 15:55:12 +0000 Received: from localhost ([127.0.0.1]:45388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4pAu-0006qX-9P for submit@debbugs.gnu.org; Fri, 15 Mar 2019 11:55:12 -0400 Received: from mout.web.de ([212.227.15.4]:50259) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4pAs-0006qF-GG for 34708@debbugs.gnu.org; Fri, 15 Mar 2019 11:55:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1552665292; bh=cCbssR1X9BPW8GOl4XAIORrUZtfNlYZrtimAM8G/rq4=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=TBHMvnMKRWFlDdh3rJZWq6EMzpBtSZyXJNL0JbkA+DWGYFqQ1+rq80h9YRWVuycB1 xHC9DEQZONrRcsRzPT2W+sWu3af0M/JQglRlLK7rb36FEP0pNjlniCk3dmF4CQhQMF QzLk62pVvOJDn6fNv3HwAul51DPiMyY0DOdLS8xw= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb001 [213.165.67.108]) with ESMTPSA (Nemesis) id 0Lcgp5-1gebIy3HQl-00k4n6; Fri, 15 Mar 2019 16:54:51 +0100 From: Michael Heerdegen To: Drew Adams Subject: Re: bug#34708: alist-get has unclear documentation References: <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> <87a7i01bk0.fsf@web.de> <871s3c14s9.fsf@web.de> <5fac8365-68d2-4cc5-b5c3-d2658350ea28@default> <87imwoyo2b.fsf@web.de> Date: Fri, 15 Mar 2019 16:54:51 +0100 In-Reply-To: <87imwoyo2b.fsf@web.de> (Michael Heerdegen's message of "Tue, 12 Mar 2019 18:55:56 +0100") Message-ID: <87a7hwqgj8.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Provags-ID: V03:K1:eWk6V79O8K1gvVFEXtvRnyNgBlKZSsamFU/IF/HWfxBM8o8eQ4I HeSNE+zJxt0xb/leEZMpXrz2jWT5rihpVsNlpCG/XTF4zebHNc7LyNvpHFQw+2s5DAS7z3I w8eCYhKalKMNTEYdr6kaeEdnZZp9a9VByaZtJ5gHZGP0JwXKQFBWkQSFgxjJuTVJzAlI1wp qF8kNsxKD7dzb+7m+Kqqw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:lwuxjejYFFg=:PHlpPtGyyg4GbxqbKPzvki oiIsH2OowEamCWvodvGOGS/dolhOODCQJa31Yf0eVql0U8SeYQQWUhIae8kutnpXY20/QrJgv mFaSJQMEeVrhY120mDmkBykkejndywWbQuOdcOIIv8gKhCPmEfRdwZFYAtkxlBNira052TCpF Bfef/baFnq3t1IOEfTsXX4hN4wpYOFzsJPavbQZQcVLZTE4lugUo9zqsOZJAir3AJwKl8FH1J DOb8V3q5f0jwbeiNvP1+NkfKTJEebROVUI5Jonc7OszaCkKXxfRRqNO6RHnO55BjuBpRQdhBy 8/ZGzpYEv4cu9qz5kg5j7T00h4NHfdhITDH+5YvqR0icHJB7Szennqns8kqerY4zKsviGfxX4 cBSYGFgx6tnm2iX+alClNrIBnNLpio+I+GeI2XIMz9pft5GKwCoI4Au6Ig8duoBTKrnEgY5ro bhn/Kf7ftIAu3DkkG/qEE3HOxZG9sBEcTQRdaFdQqipL0UpQBfSExKSODYt03QireiuNZXtuD yXMlEPDUUHdPyRbAfoZ71RfwNaD6wbDTZK1cI/28S24+rSBazWLdP/97Bg+upp3bQY5ildOpZ dlO+YpMl3B11eQwuuVm78MsKNh2qjUuBms76vysGfb1m+Rkz15dXSj4bZ+WQVb/0D35c60hId dXVDxVUut9sdYex0r5YIPrX+BF2iQnKKe6ZZb/ziRt3Z/VU9W6ld5AVZ1jrVCoPFI/LFSdlMI g7u51s0Wg0DZU+rki2OtDOR97842PfKSRlWPAvuZZcoGaUwDhl1UwcaRqA8BIrQu7bTguPRqS m9nXtxaysLa3CYITZmRBMCQ7szlfWks7uO/8GJtjcI2rsqpuDy7JvRErbtwg38y0vQBFjQpVO Kv1HgULoN5hnByBqiFn1EtPpKr8lvdG6OSOsR5YBjpuZ5y8B4X0B6m+vL3olfzZSZ80lRQyLV mnmuYAgGlpQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain Michael Heerdegen writes: > Actually, it's not even trivial at all. Setting alist-get as place > could also build a new alist, leaving the one stored in the ALIST place > intact, and set place ALIST to the new list. But it potentially > modifies the list stored in place ALIST. That's not inevitable, so it > could be worth telling that. I tried that - see the draft at the end of the message. And I tried to cover everything that has been noted here to some degree while still keeping the docstring fluent and at an acceptable length. I did not touch the manual, maybe someone else wants to give that a try? --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-WIP-Improve-documentation-of-alist-get.patch Content-Transfer-Encoding: quoted-printable =46rom 3b8ef1ee9d9a5001e2de930ec34e3bdd3d4f87ad Mon Sep 17 00:00:00 2001 From: Michael Heerdegen Date: Tue, 12 Mar 2019 15:13:55 +0100 Subject: [PATCH] WIP: Improve documentation of alist-get (Bug#34708)... =2D-- lisp/subr.el | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/lisp/subr.el b/lisp/subr.el index 4024c68e68..8ea8fb602c 100644 =2D-- a/lisp/subr.el +++ b/lisp/subr.el @@ -756,9 +756,31 @@ alist-get If KEY is not found in ALIST, return DEFAULT. Use TESTFN to lookup in the alist if non-nil. Otherwise, use `assq'. -This is a generalized variable suitable for use with `setf'. +You can use `alist-get' in PLACE expressions. This will modify +an existing association (more precisely, the first one if +multiple exist), or add a new element to the beginning of ALIST, +destructively modifying the list stored in ALIST. + +Example: + + (setq foo '((a . 0))) + (setf (alist-get 'a foo) 1 + (alist-get 'b foo) 2) + + foo =3D=3D> ((b . 2) (a . 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." +means to remove KEY from ALIST if the new value is `eql' to +DEFAULT (more precisely the first found association will be +deleted from the alist). + +Example: + + (setq foo '((a . 1) (b . 2))) + (setf (alist-get 'b foo nil 'remove) nil) + + foo =3D=3D> ((a . 1))" (ignore remove) ;;Silence byte-compiler. (let ((x (if (not testfn) (assq key alist) =2D- 2.20.1 --=-=-= Content-Type: text/plain Michael. --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 15 14:48:41 2019 Received: (at 34708) by debbugs.gnu.org; 15 Mar 2019 18:48:41 +0000 Received: from localhost ([127.0.0.1]:45510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4rsn-0007zQ-1B for submit@debbugs.gnu.org; Fri, 15 Mar 2019 14:48:41 -0400 Received: from ericabrahamsen.net ([52.70.2.18]:45334 helo=mail.ericabrahamsen.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4rsk-0007zC-VL for 34708@debbugs.gnu.org; Fri, 15 Mar 2019 14:48:39 -0400 Received: from localhost (75-172-122-141.tukw.qwest.net [75.172.122.141]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 9C649FA17F; Fri, 15 Mar 2019 18:48:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ericabrahamsen.net; s=mail; t=1552675713; bh=jkOmbHcREOSlkCesSbpcQluofWxhCnfIJZjNd7eJYjc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=vfS9OaWzkM7rB31vaL/iehQgrWwXOjjW0zxnrhV/t+DSbn+TrUoaDJQcXnFvvH1N6 oVPWhbBJk5yO/Gvee5NWtq4VsU3AIQMjzpEVAdbsuPOn9AmcHgK0jxFwWG9vCj+DWr 0xtRlObYyz9NvAWq/cMto6yvK3hsEVFiofte4rDI= From: Eric Abrahamsen To: Michael Heerdegen Subject: Re: bug#34708: alist-get has unclear documentation References: <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> <87a7i01bk0.fsf@web.de> <871s3c14s9.fsf@web.de> <5fac8365-68d2-4cc5-b5c3-d2658350ea28@default> <87imwoyo2b.fsf@web.de> <87a7hwqgj8.fsf@web.de> Date: Fri, 15 Mar 2019 11:48:31 -0700 In-Reply-To: <87a7hwqgj8.fsf@web.de> (Michael Heerdegen's message of "Fri, 15 Mar 2019 16:54:51 +0100") Message-ID: <87wol09dog.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34708 Cc: Drew Adams , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Michael Heerdegen writes: > Michael Heerdegen writes: > >> Actually, it's not even trivial at all. Setting alist-get as place >> could also build a new alist, leaving the one stored in the ALIST place >> intact, and set place ALIST to the new list. But it potentially >> modifies the list stored in place ALIST. That's not inevitable, so it >> could be worth telling that. > > I tried that - see the draft at the end of the message. And I tried to > cover everything that has been noted here to some degree while still > keeping the docstring fluent and at an acceptable length. > > I did not touch the manual, maybe someone else wants to give that a try? > > From 3b8ef1ee9d9a5001e2de930ec34e3bdd3d4f87ad Mon Sep 17 00:00:00 2001 > From: Michael Heerdegen > Date: Tue, 12 Mar 2019 15:13:55 +0100 > Subject: [PATCH] WIP: Improve documentation of alist-get > > (Bug#34708)... > --- > lisp/subr.el | 26 ++++++++++++++++++++++++-- > 1 file changed, 24 insertions(+), 2 deletions(-) > > diff --git a/lisp/subr.el b/lisp/subr.el > index 4024c68e68..8ea8fb602c 100644 > --- a/lisp/subr.el > +++ b/lisp/subr.el > @@ -756,9 +756,31 @@ alist-get > If KEY is not found in ALIST, return DEFAULT. > Use TESTFN to lookup in the alist if non-nil. Otherwise, use `assq'. > > -This is a generalized variable suitable for use with `setf'. > +You can use `alist-get' in PLACE expressions. This will modify > +an existing association (more precisely, the first one if > +multiple exist), or add a new element to the beginning of ALIST, > +destructively modifying the list stored in ALIST. > + > +Example: > + > + (setq foo '((a . 0))) > + (setf (alist-get 'a foo) 1 > + (alist-get 'b foo) 2) > + > + foo ==> ((b . 2) (a . 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." > +means to remove KEY from ALIST if the new value is `eql' to > +DEFAULT (more precisely the first found association will be > +deleted from the alist). > + > +Example: > + > + (setq foo '((a . 1) (b . 2))) > + (setf (alist-get 'b foo nil 'remove) nil) > + > + foo ==> ((a . 1))" > (ignore remove) ;;Silence byte-compiler. > (let ((x (if (not testfn) > (assq key alist) I like it! Thanks for your work on this. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 18 21:36:24 2019 Received: (at 34708) by debbugs.gnu.org; 19 Mar 2019 01:36:24 +0000 Received: from localhost ([127.0.0.1]:49397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h63g0-0004Fv-47 for submit@debbugs.gnu.org; Mon, 18 Mar 2019 21:36:24 -0400 Received: from mout.web.de ([212.227.17.12]:36465) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h63fv-0004Fb-Sp for 34708@debbugs.gnu.org; Mon, 18 Mar 2019 21:36:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1552959359; bh=qiOq9PzleVWWHE54iDlYYdFNty1Ez5Tq7MxrxKVJ62g=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=DcLAJZsgQdHdxohXFRFiB8by+Vjwtidxv7wfA/pon5RABMtLMgkYucV+Rju1PMogT 2+9YEMLrhlPdparHJkleuItKCEdWvNCepBwFxrKTwBwGr5A5cGjM2MspEpydvSIRl5 q4EjQ78Ws4P2QUbYFJF2UvQzP9V0SPop6YnBW5bw= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0Lh6QF-1gdMoD3MYx-00oTIb; Tue, 19 Mar 2019 02:35:58 +0100 From: Michael Heerdegen To: Phil Sainty Subject: Re: bug#34708: alist-get has unclear documentation References: <87wolhr5k6.fsf@web.de> <87y35xdu4w.fsf@web.de> <87wolhhz9c.fsf@ericabrahamsen.net> <87h8ckdsus.fsf@web.de> Date: Tue, 19 Mar 2019 02:35:57 +0100 In-Reply-To: <87h8ckdsus.fsf@web.de> (Michael Heerdegen's message of "Sun, 03 Mar 2019 13:50:51 +0100") Message-ID: <87imwfr6gy.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:U7bJePwVq4yFBTMRukldqJzXjo/RzbjDA5THC75b+b3tnA09KUx yQjomijEMqzNDipGG5Ev0lphnXVWYmigjFfQXnka1Q+xR2c1iKQrYxOubY3aKOE0A6OXby5 4fPunNVqD4j0H/yez9yd+qX+s+DGWNCMSRWCd0mhHOpZ4hn0pGCiI2cRz632egEKvGTBk7k JO/qCfI8B5SeFXbU5vi/Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:bY6s1mon8lQ=:nn9yN9bTbpv0vI4Fwn+JXk MdKio/CGe2Qr9pVNrLqkEQEO/DWo6Cx3H42pgnHJk/nWnc6sgotjOvzWbQX8sRg6dAdC/t86z AJY1InOZtBHS18UcNMM+GR2HSyAzgT/2XRqQ4yYQuvZuKrPz8Ix8+lAbowNS1ZNSJLT2vX2zw ZSMv5qfm88WBM8JQzd0Ycr5mpPDSdNKdYi3Y47ZamZjDY7p4H9xTkF4Gfnrn4GQdlsMruGV6T gUie8pyZSSts9N6bvf5z2UHbAEiTdvITVUQah2uPnnfe5cQ8DRpxRE2U1IJbJdweNx8logiaK T4HIf5GosJ+O6/i12PN+jh5IolW358JRVvJKYUQjmKR/r5zGT+0+SSSX63M4E6VUcJgPKRkqg iLFhJifqvmxOmbNAvMObCpLRJtI8ArQfWmnWemkyFcEi8HKIGin1dXzQ8Xc2A4UbSIdQRb/o5 E0N7P0NbY963SICsay4jUEgAcOfzPR1baplTROH+pO5s9WjkVQ8dVfUXJv5b0qa+TfIkc+jr9 hY4o62+g/9/AiTtp3cUlpaNlLO3gj6ZizJbWsVrfhPYnWHbV24tgz4dOQV3fJ/TtyUFLlAf0p klyIinjsj1toCoAZ5Cnz/ZpzCJefcX7TVBIJrey+2YEkEf2PGD5pQRFu9EKkxce5v8iH3ng+e GsWERUuUWo1d0osSZFIm1TZHXtKgUEUscaZpCLifdNeHFKlTz4rQCkhny3VfYKsO0R/5pIC2c yTWL3ZH1a3Kz1MS5vzIEPnombVBOBgoIihHLQaaeBP1yp+qEDtE1o8AiVvLy5dxB3YKcGeA5o mhrhdGjA7LXsQQQIEB6A/ohTaFcEZGAPqV6wAQzK0gBJsCJtZO2fPXErpwR7RFCgE/QtoW5Rl EgEZ5gTM5kVNmbBPnlZ0l1HYG6oiWCxFwUCbSbhJFep6+sQBOz42Temhs4Snkl4pounClJAdp mN5C4crynrA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: Eric Abrahamsen , 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Michael Heerdegen writes: > Yes, the syntax is a bit weird. I think I would prefer to write it as > > (setf (alist-get key my-alist nil 'remove) nil) BTW, I also want to point you to map.el. It has `map-elt' which is also setf'able and also works for other kinds of maps (hash-tables in particular), and a distinct `map-remove'. I guess it's time to advertise map.el functions a bit more (in the manual). Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 27 18:32:16 2019 Received: (at 34708) by debbugs.gnu.org; 27 Mar 2019 22:32:16 +0000 Received: from localhost ([127.0.0.1]:33648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h9H5k-0001TQ-FO for submit@debbugs.gnu.org; Wed, 27 Mar 2019 18:32:16 -0400 Received: from mout.web.de ([217.72.192.78]:41419) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h9H5i-0001Mu-BF for 34708@debbugs.gnu.org; Wed, 27 Mar 2019 18:32:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1553725920; bh=SXYLTH8qePsmd3dYT+2H/WZtDrnxudhGBEeWwh3QdxE=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=LWy6hFxN9mVLwcd7G5cjEcsh9dv59PL8Nwau36UXkRn2VND7hKCIo99PcrommqQKR S6qVm/USe5MP8QAho2RFkxsucghMv9xfjPpSVSsDRsRM6KPsPW+YAnDeYGtLmoOYbj v9F7xOhYiRPn4WVXQL+Pqg89oLbQeDBqdT4annWo= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([188.99.160.30]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MBCBN-1hIrrR2Pif-00AHZw; Wed, 27 Mar 2019 23:32:00 +0100 From: Michael Heerdegen To: Eric Abrahamsen Subject: Re: bug#34708: alist-get has unclear documentation References: <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> <87a7i01bk0.fsf@web.de> <871s3c14s9.fsf@web.de> <5fac8365-68d2-4cc5-b5c3-d2658350ea28@default> <87imwoyo2b.fsf@web.de> <87a7hwqgj8.fsf@web.de> <87wol09dog.fsf@ericabrahamsen.net> Date: Wed, 27 Mar 2019 23:31:59 +0100 In-Reply-To: <87wol09dog.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Fri, 15 Mar 2019 11:48:31 -0700") Message-ID: <8736n8x82o.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:4twxx32FYMk0RY1Cjl8rIdzkOzgoIv7DdRJj1zOMFIYpZR5Rb2e dRgRTC8+0UtN4BVGEJaQHpdDaeFjarkpETPm4dszWW2snNqh1sTGlwSlM6JLL9SPnDKbFkF n/G734/t9qCdPmjUWw/ah/GdAtu6IEqnCnb/0xtufs05ABtrPW6/gismU127RTbLZh0E9I4 IedvHiJONtGtGs4VTTaWQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:BMXTXdGsCMc=:HFly2REPIM/KtHb/VlVlqn S7aqQyVrDPrbqqtP9moZhdv7+gwiNJmnScwmmfG7P6D3BI7GKIOByv0QnqJIlRx/p1fiHp5O4 kiBX15bj1729aFaLiUePNnH+N1JSNULadbxubtLya392qvi1J6Sj9URpT42H/zog9yj+1i+mH +JWvYt/RuLvblGqZSlTJN7i2pxdwPC+MguxS+RreLbtySo5/y7S8Df93w4ZOJQYfBT/+7bK0v 75VH625+uRENc950WhEBH8qU4tQFZBtNRMf15yosaCZ2kM2unM3yi9jd5q88lo6QMA7gFT/Gx woE8uwQxNMRCZE1S41s8jIqHusiMrE/Yf0uoxUN0bq5Sdi1EQVbVDs5sdSd58h0mUFaeZ86A0 JeDmMhh92OV99Zq+PrstqPaaKmub0tQ0vFT2Hdop7WrUpyaRAexxL8ADBcGatQF11G+n2kYSk dor2Fc8RAK7rgtg4RAKi6EYMJvNohjzJD2X/Yd1DZrLAk5P0FNk5C25oeFQjyrfO9feg+rxcG fsChkFRM/cqyGX4qE4CbZNHA1E0W/rYR/siyAvL6LqKfllys1fMDReWfEal4kSzm0+fwPYMVZ 9T7pTUocbzZBIQpSP/DRgf5jX5+baVYj4t6E4ECBSPJ24CZcblxrBVCmQCrD8lOucA0VjixQZ GQBzjP5PcVRz9G7NmOGOzkTyRbKVjZpd3VoEWENfIC9VzHxb4djq6UFneMpvLFAVPwtCTnNH3 GFeYmrSMGt4cn5ZiMlWQTv5cxwsO7Wqqtj0yE1z+vkUGDsbJHW/24hEmh46KU6yIfkdvtjRIA nr5yuZKEXBtEcYPY20q36yvfsl8fTmfTvVFAh9CVGJAFe+p314ES1muj7+arvGpiFBET2O6j5 yaZxQI6KpLoUeSNM7wm+30OcIOC/RN/IDeU3zZ1fJKtdCKK78OYPDMVE/6v0u9RlDr+fcpyIx gJEzE+e3Rsg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eric Abrahamsen writes: > I like it! Thanks for your work on this. Patch installed (master). Can we close this report? I left the manual section about alist-get as is. It is not perfect, but what I really would like to have instead in the long run is a chapter about map.el functions. This is not subject of this report, however, and I'm not sure if map.el is mature enough to do that now. Thanks, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 18 21:33:22 2019 Received: (at 34708-done) by debbugs.gnu.org; 19 Apr 2019 01:33:22 +0000 Received: from localhost ([127.0.0.1]:42819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hHIP4-0000a5-Gx for submit@debbugs.gnu.org; Thu, 18 Apr 2019 21:33:22 -0400 Received: from mout.web.de ([212.227.15.14]:45967) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hHIP2-0000Zs-8T for 34708-done@debbugs.gnu.org; Thu, 18 Apr 2019 21:33:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1555637584; bh=rwnMI5BOUPKC3hjqT6HzK6BfiBEsdYr23s+738S3dII=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=Rs6AEvolsIxPMSBGZlpwtNu7Y+t7ouu5/L9WrvUihFAW7uLre4n1gAanX/Sz6JUAW 2x1G/y8Uvd/kR9TE7xYRyfwLSOREZxP/0gV0Yditzcd2y3yJTiiqqGm/wbWQflA1g9 TilOftIa4lZ1bhjkAJqMxu92A0zOmLYkWnci9374= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([92.208.95.234]) by smtp.web.de (mrweb003 [213.165.67.108]) with ESMTPSA (Nemesis) id 0Lo0YS-1gbf7Q1ria-00fxi0; Fri, 19 Apr 2019 03:33:04 +0200 From: Michael Heerdegen To: Eric Abrahamsen Subject: Re: bug#34708: alist-get has unclear documentation References: <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> <87a7i01bk0.fsf@web.de> <871s3c14s9.fsf@web.de> <5fac8365-68d2-4cc5-b5c3-d2658350ea28@default> <87imwoyo2b.fsf@web.de> <87a7hwqgj8.fsf@web.de> <87wol09dog.fsf@ericabrahamsen.net> <8736n8x82o.fsf@web.de> Date: Fri, 19 Apr 2019 03:33:03 +0200 In-Reply-To: <8736n8x82o.fsf@web.de> (Michael Heerdegen's message of "Wed, 27 Mar 2019 23:31:59 +0100") Message-ID: <871s1y3hkg.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:iOGk0PgoqpUVQTGlLggrAMUZzSK+VVM39OLGy6UKAxVEKnWXWYn y0iQHGOi4b6aor4c4atTZR6MOivRWp//hAuOzAKKY0GA9yqHKx0uOE3p13Yr3k97YYN9ehU RTbvbaCuX7Ldu/8AMsrhWKFLRkUh8Gt3+J1p3zRuTGPPLHyDaSHHybRJF9qU9nAyeAmDxRX hpRfUmOb2nlwdhZ06aNQg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:OIWDsUaIrL0=:tx0YBR9EyfkUea3BY94DKb 8EbPQf3K8VBAeN36PyR/RQ7B60vRdUq3swHdcyDCAWAieZkEZCqLUmncpxaFAlXndWWPNZ2Bf Ct0Qyow6zvuS2mqEm4u1GFKBo00rFPt4m1LfNQZy74OJh8hUtg8bGBTJaHnnocZ0RyyU9MaQI 6cVyeoLv7o6kMPiv4jgpbPdbqiYc7DCs6pH2TFJvEmcKyauP9m7v5GjykWUbypIFJGSOUrE2V uxAXpz8Ij8vNLcHxQzp9lThLJM2lha5gIs13/nEEUcWOtTIfUed+/BGeDaSg4tqBOKOVbiG/Y /rmFUGhIfh5/RtaWJchxlao3oMoa6ELdlgQHjRM3tR9eLNlc3u06BIf2tcL4DEJh5bpQETXnJ HwjTjrUhmC9melmBkMOUhiWkpnxzVWFbW7dycX03q80BwxBUNd4AwyEbjIe7MCrewb3dNvcth s8V2eUeT16Ex5TxiNXpmc0us0GtSm2agzctMF/lu1Ryxfs1whUIP6/peNua3YA7wJk0F71ABM kKz5EMWz3xCyoAjHNkTrzEDsmSirq6p5LZ7AOEcGs3m27UwnFNj3+2TZrzWpfNX7svQo6rM8i Xeqng2wzZ3xXIY1Cl8uwuVsZTIkfZNI+pJxZbUUmJGPIJr4Ss4drtyz7HTQhyks2usgAH6LJo 6RelXEt/fy9dM1UWl+2DZyGhcsEMnoGBuWOSYDTfSPp6/eBzzKCYympUekLGvuZc5WkJafQtC 0ezG4yBavmtlotxAAGuN5y57vfhag2DSBPk1Lko33cOn+lpJ2BkI5B/0+6Mhz/bTfSHhp37Au jOGeMxWSoUJQF19nQAEfLMw1EoswV+LTA4EBt4Z1ML7VXrfz/IKxJL1qMkEXvj5iFnkQfIa4P H7XkwWJ0YfXQVQClGRrgOT0mejlTO5SIgooZMJMyFu0RfaEyQuWdrFsLEs/6p14rNE8CjEGRB 89UWUZ2fdUg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708-done Cc: 34708-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Patch installed (master). Can we close this report? > > I left the manual section about alist-get as is. It is not perfect, but > what I really would like to have instead in the long run is a chapter > about map.el functions. This is not subject of this report, however, > and I'm not sure if map.el is mature enough to do that now. Ok, closing. Thanks everyone for the discussion. Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 18 22:24:59 2019 Received: (at 34708) by debbugs.gnu.org; 19 Apr 2019 02:24:59 +0000 Received: from localhost ([127.0.0.1]:42862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hHJD0-0001sR-S5 for submit@debbugs.gnu.org; Thu, 18 Apr 2019 22:24:59 -0400 Received: from mail-it1-f177.google.com ([209.85.166.177]:55912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hHJCz-0001sB-EP for 34708@debbugs.gnu.org; Thu, 18 Apr 2019 22:24:57 -0400 Received: by mail-it1-f177.google.com with SMTP id y134so6356022itc.5 for <34708@debbugs.gnu.org>; Thu, 18 Apr 2019 19:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=K2CWuGj65mkYM3VKcuDN479F6Yd9dI6PdtE3CZ85/As=; b=A8COK5BcCq5f2U19B2ERRKTppZbi+J9bgZPg4kwCjLoazaMv5Rmftwb9bLeuKvrT12 fVjPUGDcCfvIl6jSjpKySMtpSQKSmnpEUdHHiwVepYRz8mVdRr0TgWmYgnsLlhCxYvHP TUp4Ievi+AYMePWGby/9eIEATdnmRwCaGRtGxVgdV6N1s02doHgGX7ChjYULjlVxhE7L G1E4nSUi34b9RarSDlFQZvYCGx8akocxaDEVRuGty6OEhpIdQOMNhJ+E385o83UoeILl mZmzzl699i53adTzCJvcpcIjs1vlB+jwJbIv4aEJnWdrbXWQdjiPOdgfrpmodaNrYnT1 c72w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=K2CWuGj65mkYM3VKcuDN479F6Yd9dI6PdtE3CZ85/As=; b=i9MhspSVM4q3i86hO1XRNFs3uMnUFOUudYnq5qThXPNr9mZjiArg4iMfyHhbAXDVn/ LLaSMlfDRfyQTxN5oB91nMTAIWPXl65n+1OPhDwZ/l8SQATwlVSDXqd2ccvofXhiCyDX HZYO4F5uvr7IuF3LS68tXHk6wXB+9sUGqYnMB3YDRiS5lSlfWP2P3+JQ7HDocF8aAe3J qKM8D3m4quvZDg5XuB0WmauDIHEgGD6T/tv8LiSZREjmeYaf5xNBNrulsbOepa5y9NuR nxY2wjQX5fjKBiMplrUvANhcfCn+P/RQ2Nr0FzPkcgb/34idPUerGqRfsFU1W9yP9Oaj ZKUg== X-Gm-Message-State: APjAAAVChkv5rZHh7SwPT6z5Wy9bpMvYPsy/vVBVSixpwEln13lL6V5h LlFDHsIlOLvaiOdJkANslyooE0rXxcFkISAagWn59Q== X-Google-Smtp-Source: APXvYqwt/oTt3nTy7puEhW2Wk9u87RrMHZnov9nA+s8pd06qaeSevUGBcWo1hAzEgKNd6WRgO7WKDaC6oqnALot8tXo= X-Received: by 2002:a02:cbda:: with SMTP id u26mr922757jaq.7.1555640690378; Thu, 18 Apr 2019 19:24:50 -0700 (PDT) MIME-Version: 1.0 From: "Miguel V. S. Frasson" Date: Thu, 18 Apr 2019 23:24:38 -0300 Message-ID: Subject: Thanks To: 34708@debbugs.gnu.org Content-Type: multipart/alternative; boundary="000000000000bf8e2a0586d8d24c" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34708 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000bf8e2a0586d8d24c Content-Type: text/plain; charset="UTF-8" Dear all in this discussion I learned a from this discussion, specially about how to use alist-get. The only missing lesson was how to remove association of a key from alist using setf and alist-get. Could someone give a quick example? Best regards Miguel --000000000000bf8e2a0586d8d24c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all in this discussion

I learned a from this discussion, specially about how to us= e alist-get. The only missing lesson was how to remove association of a key= from alist using setf and alist-get.

Could someone give a quick example?=C2=A0

Best regards=C2=A0
<= br>
Miguel=C2=A0
--000000000000bf8e2a0586d8d24c-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 19 00:18:22 2019 Received: (at 34708) by debbugs.gnu.org; 19 Apr 2019 04:18:23 +0000 Received: from localhost ([127.0.0.1]:42891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hHKyk-0000Im-ME for submit@debbugs.gnu.org; Fri, 19 Apr 2019 00:18:22 -0400 Received: from mout.web.de ([217.72.192.78]:49409) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hHKyi-0000IS-Ku for 34708@debbugs.gnu.org; Fri, 19 Apr 2019 00:18:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1555647492; bh=oF5vCHPSNO14nJT7xkOB4VCfdpKH71FEeRIHvBwEPJU=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=hiqF1tBTDLAAa2SR0DceESoyY7KYD8uMb0WiELs4Nvv/eIX8xsk87ctK3CeMsvO+p wiQdCgd66Auo2rD21P8NAICfYPV49HBQtmX9Ibxu9Q9YozU/rixLB3u7k/0Rxw6lWA 2lOO86GLfhcjUi0qun0IrJxBqAIM4a3OewWIS33c= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([92.208.95.234]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MQ6PP-1hDEVr0xwR-005G9K; Fri, 19 Apr 2019 06:18:12 +0200 From: Michael Heerdegen To: "Miguel V. S. Frasson" Subject: Re: bug#34708: Thanks References: Date: Fri, 19 Apr 2019 06:18:11 +0200 In-Reply-To: (Miguel V. S. Frasson's message of "Thu, 18 Apr 2019 23:24:38 -0300") Message-ID: <87imvay6f0.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:pMKGmkot6tdWwfXopp3u13rRRW5iP0O0RCZyF0K6uhY7XLR/TG3 64GBjaL6mkAm3Meyb1OgS+JQiWhwXKGF8Jet6ahDUYfWHXGMYDBWYYroTRfooeiRtDPpLd/ 6wFY0JLML+4JxyP5XSlaumx0NbyPQwKxxL7z9BgLLBeazAN+d56gZn9LtkbhNzxN3omvc0Z o8N09kIGMLeLCP9I9vSAw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:sS6dLIWiF94=:DfZyofdLp2aPwHybo9M67X e2ix+/w9l8HMsH6h++8/w82q2Bm6cWiYeeMHdxXAVC3z+ntFgLypNU9iLPFZSllb4CusRhtBZ rVo9/bhMY2X7nrGZhi8owqk7LPJH44WpXakkUIIanBDOsbNRgxQxhkuo6N50APWqEgiaTQBP4 wj7v8t84zxiOSbvxJr0rivuiC5Lh/8T9j8yg4nkw4XaJhQetwtw4YTo/ej/hAeol86BSG8Z9o AWvSWC8ardpCP36FjgHdHpGioWDrhTf+Rx8KxqVnoXWq07BLX9YJOgiAXpeEg5CILJFiCQgbY UcIhytzCx4/5GA5Lh25YC5PRbpDm7imWYb2cBR+PtW1nzKB27DctUCRSrRVDsBM/gwC8ZEOVM qwPUEcvPbfhSRu+vaPu0RwbVvToKynmyeGUBLL4cDTSCPYrQX3b/EQmtNJUwmxYvDrZO/PVen BN5dAWI9IZt0RJD0IvfvMAYSYy+Meko4bv8wUdx0DysOhZevmk9FiHgjzMrVxtqJYd+Jy+WiK j3CTV9xTVrrgcj3CkiUBSiX4eVVqlLzw9fR+Xad2vUVu4PTQcIuAY3HPw26tTy3SVTFMyFt8I uFMrstaXFsX76R/iuEeHIAq/eLfncOXaROqFr9O82hhWIJFMjOIlkLGxwI3EuVnPzOWpp4IOd 4LNQJTRDztvlv+LhNLPcwOETayv+ovFqvVqoGHkFcYPK0iUDt/nzkQgNPmGiyPGzvr65GbfHg JjLKs7K0pLLy1p7DAPfb5LozGqm7e1b3m7H9Xx4XhdztIIuuI4f5jcRokfGLaNZrU/Evl2a49 6m/+GKOzfURR6VrTqzBHeYL3HafhLLxc5zCS7aCEXi6CUt1bbwNei3uBLoM9oF40tfgJvdF6e PYKalqRl0Kc7xHUxnrBcRdfyBNirJncKhks675qXMdZ2nbAHdQtXKmFPxbYmLvACvXN6AN1ns Faw9m7KVd1g== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34708 Cc: 34708@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) "Miguel V. S. Frasson" writes: > I learned a from this discussion, specially about how to use > alist-get. The only missing lesson was how to remove association of a > key from alist using setf and alist-get. > > Could someone give a quick example? The modified docstring of alist-get has now an example. It says: [...] 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 (more precisely the first found association will be deleted from the alist). Example: (setq foo '((a . 1) (b . 2))) (setf (alist-get 'b foo nil 'remove) nil) foo =3D> ((a . 1)) Does this suffice? BTW, it doesn't say you have to use this feature. If you find it confusing, use delq+assoc+setq, or alternatively, what map.el provides. Regards, Michael. From unknown Wed Jun 18 00:25:49 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 17 May 2019 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator