From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Imports / inclusion of s.el into Emacs Date: Sat, 2 May 2020 09:49:57 -0700 (PDT) Message-ID: <5f91c6e5-b4af-4478-b221-4ca37f0fb74c@default> References: <> <> <<83368ivmym.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="97053"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii , rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 02 18:50:54 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jUvLp-000P9G-Sb for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 18:50:53 +0200 Original-Received: from localhost ([::1]:51492 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUvLo-0005UK-U2 for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 12:50:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUvL3-0004WK-Hv for emacs-devel@gnu.org; Sat, 02 May 2020 12:50:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUvL2-0008Mi-H2 for emacs-devel@gnu.org; Sat, 02 May 2020 12:50:05 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:40494) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUvL0-0008KM-3o; Sat, 02 May 2020 12:50:02 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 042Gn7aw125840; Sat, 2 May 2020 16:50:00 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-2020-01-29; bh=+1RCXCIn6Id0tOBIZpmXpmZStFtTh5bOi2K6k6CBIaE=; b=TInP7Met2pG7FSruYEO50agSla73D1dkdEdxOPqy0RsMfamZIk5uTnp7MVfDomFHflqb weiQqtwjkAiyAb3hSd5sIHx0IP42Ozz/be1GABl9rP67JsNy2QpPazD9Po+LysNO4PCx iMIMYAYJOBHOGXbMOILETAVEfZvToSSMljh4CLu+7L/vSJZ6KgKwrzGct4JsYjf/c/Rt 5TPqK8XLR7MyPKeEL2cg21CgBryqKSUEda1cqyoPZdm9TxP5Zrg6KCVaaPw/adpUgaFN iY5jOHJG01S/AZQy4yDNnmou7VXZhJqlZZCgrq2OBzmwCwD4/Xxy+6TRqg/ghIPMaBW3 MQ== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 30s0tm1fen-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 02 May 2020 16:49:59 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 042Gl5BL019566; Sat, 2 May 2020 16:49:59 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 30s913b5np-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 02 May 2020 16:49:59 +0000 Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 042GnwHJ031229; Sat, 2 May 2020 16:49:58 GMT In-Reply-To: <<83368ivmym.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9609 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 mlxscore=0 bulkscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005020148 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9609 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 suspectscore=0 phishscore=0 clxscore=1015 bulkscore=0 mlxlogscore=999 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005020148 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/02 12:49:53 X-ACL-Warn: Detected OS = Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:248496 Archived-At: > > Renaming 'concat' seems also like spurious inconvenience > > in the name of rigidity -- the Lisp equivalent of=20 > > bureaucratese. Yes. Spurious inconvenience for users, even if well-intentioned. > We all do keep in mind that 'concat' is about much > more than strings, yes? Such polymorphic APIs are > IMO a problem when a simplistic re/naming is considered. Exactly my thought. Likewise, `format' - an even better example. ___ The idea that every function that returns an XYZ instance, or that operates on one, should have a name prefix (e.g. `xyz-') that advertises that fact is, well, somewhat silly, and it can border on dogmatism. My guess is that this is coming, not just from an Emacs UI question involving prefix completion and discoverability, but more generally from the widespread influence of OOP, where categorizing or grouping of functions (methods) etc. by type (class) of object acted on or returned has become ingrained mentally as the only or the best or the main way to organize them.=20 That things _can_ be usefully grouped thus is not a reason why they always should or must. That may be a requirement in some OOP languages, but it's not so in theory or in other programming contexts. Functions are more varied than what's necessary to define an abstract data type (class). Yes, a particular set of functions do define an ADT, but other functions can also make use of it. It would be absurd to name every function that uses or returns an integer with prefix `int-'. (Polymorphism can help get around this in OOP.)=20 In Haskell, do you name every function with a prefix that advertises the type of its return value or one of its main arguments? No, of course not. How do you find functions that return or use a value of a given type? You check signatures or doc. As for "alist", "ass(q|oc)", and the like: each such choice has its drawbacks. But yes, some name consistency can help, in general. But no, because history. And no, because different uses/contexts. The discussion was motivated by considering new users, in particular. Well then, what does a new user look for, when it comes to alists? Does s?he know the term "alist"? Or is the thought about "association"? "key-value"? "pair"? "relation"? "attribute-value"? "property-value"? Consider "plists". Does a newbie whose heard something about them and tries to find relevant functions look for "plist"? "property"? "prop"? "tag"? something else? There is no blanket, simple "solution" to this, because people come from different places/contexts and think in different terms/languages. Should Emacs generally be consistent? Sure. Could it have been more consistent at the outset (Lisp Day One)? Probably. Is there now, here & there, room for improvement in naming functions? Sure. Should we be wholesale-renaming stuff, especially to try to fit what the latest generation of newbies might be most used to? Absolutely not. Names should be considered case by case. And there's zero "fierce urgency of now" for any particular renaming Long March (initiative). ___ Don't downplay the use of matching against more than the function name. As Eli mentioned: `C-h d', which matches also against a function's doc. And as I and others have mentioned: more flexible matching methods. Consider `C-h f alist', with substring matching. In my current session I get 156 candidates, all of which are relevant to alists. Great. If I match `ass' instead, I get 235 candidates, many of which are about alists, but many of which are not. If I then chip away from those matches the matches for `class' and `pass', I get only 51 matches, of which 34 are about alists. (The 17 matches that are not about alists: ad-assemble-advised-definition 2C-associated-buffer ad-assemble-advised-definition assert byte-compile-associative byte-optimize-associative-math byte-optimize-nonassociative-math cl--assertion-failed cl-assert disassemble disassemble-offset glasses-mode gnus-atomic-progn-assign image-dired-associated-dired-buffer image-dired-associated-dired-buffer-window message-disassociate-draft nndraft-request-associate-buffer) If I use `C-h d alist' I find 560 functions whose doc mentions "alist". `C-h d association list' finds 56 functions. `C-h d assoc' finds 52 functions. ___ Finally, the habit of assuming that functions should be grouped only by argument or return type, either in terms of name or doc, is not a guide. API doc (e.g. JavaDoc) does have its uses. And it's especially useful, perhaps even necessary, for certain kinds of languages (e.g. OOP). But it's certainly not the be-all and end-all. Lisp is not Java. Discoverability for Lisp is not discoverability for Java. Doc for Lisp is not doc for Java. It does take some time for a newbie to learn to "ask Emacs", including wrt using Lisp to ask. And sure, we can help ease entry. But that's not a reason to try to mold Emacs help (including naming) into only what newbies might be used to in other contexts.