From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: map-put! and (setf (map-elt ...) ..) on lists Date: Tue, 18 Dec 2018 07:34:02 -0800 (PST) Message-ID: <150bbe9c-3ef4-4d43-9fce-23d608abd829@default> References: <87y38p4ely.fsf@tromey.com> <8b3d6cc4-43ac-48cc-be4c-917f601faa43@default> <87imzstm6v.fsf@petton.fr> <89a74aae-cc0d-4fea-aeef-1e4afdc518e5@default> <87bm5jm9eu.fsf@petton.fr> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1545148679 1869 195.159.176.226 (18 Dec 2018 15:57:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Dec 2018 15:57:59 +0000 (UTC) Cc: Tom Tromey , emacs-devel@gnu.org To: Nicolas Petton , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 18 16:57:54 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gZHkn-0000Li-6C for ged-emacs-devel@m.gmane.org; Tue, 18 Dec 2018 16:57:53 +0100 Original-Received: from localhost ([::1]:54731 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gZHmt-0007Ft-RD for ged-emacs-devel@m.gmane.org; Tue, 18 Dec 2018 11:00:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gZHNu-0005h9-HN for emacs-devel@gnu.org; Tue, 18 Dec 2018 10:34:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gZHNq-0001ut-Mu for emacs-devel@gnu.org; Tue, 18 Dec 2018 10:34:14 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:51270) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gZHNq-0001tU-Cj for emacs-devel@gnu.org; Tue, 18 Dec 2018 10:34:10 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wBIFTK7J081198; Tue, 18 Dec 2018 15:34:07 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=uG7KSMV3AhhHBtGqNbKpertDaVcZW5LyxssA7cnPew4=; b=2XQtkX6IMuDVjEUNVobgDITEnwo7okaEkwt2bWt8kpCN9ZnJsZlvEhAxRHh2C1r/h651 chiHpIuQNK3Zgo9OrhSI3KkR9dKe5IL1roKUuNRRcKSURuwvjUUJ3/blMMkRD+mIg7Cc grfxFHgXt8AQMLzbhQ1tIsw3GKCQAUX7g3r/qUnMYRw1oQdsefFx8mC3KHJNH2RUw8fR eaSPFMy0y7hf2pskX/VcaFKmJFHDDzcQDAKXuIvdHEojyZ9j7AeeAVepRXLZeHylYAnw RwsTFFd62qttuWcTNfEe9ZrFRWSDofEMxWto/pmmTbngYhz7yqc6IdHMm9NNPbS9gkEN zw== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2pcs1tm5g9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 18 Dec 2018 15:34:07 +0000 Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wBIFY5OQ023458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 18 Dec 2018 15:34:06 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wBIFY3cq024369; Tue, 18 Dec 2018 15:34:05 GMT In-Reply-To: <87bm5jm9eu.fsf@petton.fr> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4771.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9111 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=462 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812180131 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.86 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231907 Archived-At: > > Do we have a non-destructive `map-put'? >=20 > There's `map-insert'. My point was that there is no need for a function name to signal that the function so named is "destructive". The doc string should do that, however. The only case where we might need a function name to signal this is when we have two functions with exactly the same name otherwise, one "destructive" and the other not. There is macro `map-put', which is supposedly obsolete now. It would be fine (IMHO) to just name the new, "destructive" function `map-put', IOW replace the macro that is anyway obsolete. If we did that we'd need to post a notice (in NEWS and the doc string, for example) that we've made such an incompatible change. Probably not a big deal. > > Much more important than the function name, however, is > > the real answer: Put the important info in the doc string. >=20 > The docstring, yes, of course, but the function name is IMHO the most > important part of the documentation. The function name should, yes, say what the function does. But it need not always say how it does it or whether the action might change list structure etc. Or if it does then that should be done systematically, for the names of all "destructive" functions. It is misleading in Lisp to have some "destructive" functions signal that fact in their names, and others not do so. And as I said, if you use such a function in a function you define, it can often be the case that your function is, likewise, "destructive". Are you going to name your function using such a name signal too? And so on. It's a contagious virus, which we generally ignore, in terms of propagating such a name convention. Again, just one, no doubt minority, opinion. I express the opinion, but I don't expect that it will have much effect. =20 > As I said, I like Stefan's approach, but if everybody else dislike it, > and if you think it's not idiomatic Elisp, then let's change the name. >=20 > Stefan, would it be ok with you? I don't think there is a standard idiom. Some names indicate (if a user knows the particular convention) possible "destruction", but others do not. An old user might recognize that `nreverse' is a "destructive" `reverse' from the name, but a new user might not. The doc should be the place where we make very clear what a function does and whether it is "destructive". If Emacs does want to follow a convention of naming "destructive" functions then it should do so more systematically, IMO. (And IMO it should not bother to do so.) In that case, apply the convention all over the place, even including renaming (but keeping an old alias) functions such as `nreverse'.