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: Mon, 17 Dec 2018 08:07:03 -0800 (PST) Message-ID: <89a74aae-cc0d-4fea-aeef-1e4afdc518e5@default> References: <87y38p4ely.fsf@tromey.com> <8b3d6cc4-43ac-48cc-be4c-917f601faa43@default> <87imzstm6v.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 1545062779 24519 195.159.176.226 (17 Dec 2018 16:06:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Dec 2018 16:06:19 +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 Mon Dec 17 17:06:14 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 1gYvPI-0006Bw-DL for ged-emacs-devel@m.gmane.org; Mon, 17 Dec 2018 17:06:12 +0100 Original-Received: from localhost ([::1]:47611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gYvRP-0001xN-4m for ged-emacs-devel@m.gmane.org; Mon, 17 Dec 2018 11:08:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gYvQL-00019H-Jt for emacs-devel@gnu.org; Mon, 17 Dec 2018 11:07:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gYvQF-0006m7-QR for emacs-devel@gnu.org; Mon, 17 Dec 2018 11:07:17 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:48754) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gYvQF-0006je-An for emacs-devel@gnu.org; Mon, 17 Dec 2018 11:07:11 -0500 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wBHFx0rg134740; Mon, 17 Dec 2018 16:07: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=jyDoIGCFb8DzALWD/AZrBs9EkwwnRS287HLsd5YHP0I=; b=Rj9aeqJvJ0wTFu7lUQZxQMe8NxdlxbsPhS63U3Vw25QL3DML/IJusHMNNFE4o4PHwojN XUuAQLLHUuOligaTP4plxMMNSvrZnMcGZAvY++asxPeL/+oogH9TKwHhTL4rYtIO1rVM 86fulJH/3WRK7KinJrcPvydr6kC37aWvwtBZxOknHWU+S47PTIoAje2qqfXYcspZzu3V xFAMYpRWMwNpCGQykAISpDefbrRY0hZUJ/tEd/8/02rohs0f0RUGMnTILV/hxtXVToLv nllc+go0BLVLYMiJMhKiAPouWFnWOSL2Cpxsd4r3gVe7202n4fM9AP52Yk8coqYmls39 8Q== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2pcq4dpnd0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 17 Dec 2018 16:07:07 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wBHG7584020160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 17 Dec 2018 16:07:05 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wBHG74KV004708; Mon, 17 Dec 2018 16:07:04 GMT In-Reply-To: <87imzstm6v.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=9110 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812170143 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.79 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:231882 Archived-At: > >> So really than complain, please provide constructive alternatives. > > > > Or just go and rename it directly. >=20 > Given that seq.el is completely free of side-effects (IIRC, there might > be exceptions but I don't think so), and that map.el was done mimicking > seq.el but for key/value collections, I like the idea of stating > clearly when a function of map.el mutates the argument. Only when the same function exists in both "destructive" and non-destructive versions - such as `reverse' and `nreverse', should we bother to reflect that difference in the function names - somehow. And AFAIK we do not have a convention for doing that. (Some old Lisp functions use prefix `n', but that's not great.) Do we have a non-destructive `map-put'? I see that there is a macro `map-put', so I guess that would qualify. But no - that macro is now obsolete - replaced by `map-put!'. Much more important than the function name, however, is the real answer: Put the important info in the doc string. That's what should have been done at the outset, and AFAICT it still hasn't been done, here. I see these doc strings for the obsolete `map-put' and the new `map-put!', respectively: map-put: Associate KEY with VALUE in MAP and return VALUE. If KEY is already present in MAP, replace the associated value with VALUE. When MAP is a list, test equality with TESTFN if non-nil, otherwise use `e= ql'. MAP can be a list, hash-table or array. map-put!: Associate KEY with VALUE in MAP and return VALUE. If KEY is already present in MAP, replace the associated value with VALUE. The only change was to get rid of the last two lines (the first of which is too long, BTW). Whoa! Nothing anywhere there that says whether a copy is returned or the original value is mutated. That's a bug, IMO. If you really want clarity about whether a function is destructive, put it in the doc string. That's the real answer to Stefan's quandary, "Don't use "!" as a suffix" doesn't say what to do instead." That's the place to start. And unless there is also to be a non-destructive version, and we _need_ to have two different names, there is no need to have any name indication that a given function is "destructive". (Just one opinion.)