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: Sun, 3 May 2020 12:45:34 -0700 (PDT) Message-ID: <8d649ffd-c60e-4cb5-ae21-413cc39ae409@default> References: <83368ivmym.fsf@gnu.org> <5f91c6e5-b4af-4478-b221-4ca37f0fb74c@default> <2afdde98-4d71-4847-8ee4-b0eee677baef@default> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="3427"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Stefan Monnier , Richard Stallman , Emacs developers To: Philippe Vaucher Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 03 21:46:17 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 1jVKZ7-0000mf-Dm for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 21:46:17 +0200 Original-Received: from localhost ([::1]:33060 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVKZ5-0003FX-F8 for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 15:46:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37032) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVKYZ-0002of-Do for emacs-devel@gnu.org; Sun, 03 May 2020 15:45:43 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:44360) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVKYY-0002U5-0d; Sun, 03 May 2020 15:45:42 -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 043JdPuB116563; Sun, 3 May 2020 19:45:37 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=vnXfYcUlr7EFbDjTuwHGjwrsCyMOlM5P7dMkhRBiSO0=; b=OS0Kzyla1VKAYje9joAeWfu4q4X+zbfx0scxLDNnuZafY3veO0cdH/xkNRf1lYUijWlP m+AGL+DSWLNH4SonPL7jE5bzsn1ndXjt4jGbGZwcs2VUWxkTZqrt9QKrDoNiNVUoB4oF uWH70wJO5kLdW979GJMGXpX8AXzJ/CSEHUb2NjwXgVszTc9AtJ7Uy0YY3Q9z2VR3Sq1n YJK/olmcLjCLN7IFhLmVBWFGh0vO1RFASTtqLHgHlLPhzxH+GKCKnkLabA5t7GQPqZhN li6raFk26oPSINJGbNoPxkZJena/E0MtZbG7SbmGHG3D/cnLh9D6RkN7/pqV7Hvk4VPo qA== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 30s0tm3wcr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 03 May 2020 19:45:37 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 043JbZPk064038; Sun, 3 May 2020 19:45:36 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 30t1r0fagk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 03 May 2020 19:45:36 +0000 Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 043JjZPB030767; Sun, 3 May 2020 19:45:35 GMT In-Reply-To: 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=9610 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005030176 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9610 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-2005030176 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/03 15:07:55 X-ACL-Warn: Detected OS = Linux 3.x [generic] [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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:248736 Archived-At: >>> In Haskell, do you name every function with a >>> prefix that advertises the type of its return >>> value or one of its main arguments? >> >> [... replies pointing out that some Haskell >>=C2=A0functions do prefix their names with type names...] >> >> I suggest those of you who think that Haskell >> too deserves type-name prefixes for all its >> function names start an initiative to rename >> its `map', `add', `zip', `head', ... functions. > > notice how in Haskell there is a strong will to > group things together. That's what you'd take out > of the example. Of course. In Haskell and in life generally. Things that are alike generally belong together. But this discussion is about _naming_ functions, vars, etc., not just grouping them. In Elisp, grouping them in a library already gives them a library prefix. And in general that has nothing to do with the type of objects they use or return. I should also point out that my initial question was, in particular, about Haskell code that you write, (e.g. for an application), not Haskell library code. In the wide world there are many, many more functions that _use_ objects of various kinds (types, classes) than just the functions that are needed to _define_ those kinds. That's especially true of a language like Lisp. What you call "generic functions" are not corner cases in Lisp. It's even true of a typed functional language like Haskell, I think: lots of functions need not be associated with just one data type. (They're type-grouped by their signatures, of course.) But forget Haskell as example, if you're not convinced. It's true of Lisp, in any case (even CLOS). But it's not true of OOP. In most OOP languages you pretty much _have_ to place a function in some class, e.g. as a method (which typically privileges one of its args as the target object (which is in that class). (But in most OOP, there's no need to add the class name as part of each method name.) It can make sense to adopt a prefix convention for functions that define a type of thing (e.g. buffer, window, vector, string) than it does to impose it willy-nilly way on functions that might just return such a thing or accept it as one of their args. Most functions do not fit that bill of defining a thing type. And many (most?) do not fit the bill of acting only/mainly on one particular type of thing or having as their main purpose to return such a thing. That was really the point. Perhaps there are some cases in Elisp where it would make sense to prefix more functions that involve a particular kind of thing. I've acknowledged that. And others have said the same thing, citing strings as a type that might be looked at more in this regard. My preference would not be to name string-related functions as a whole with a `string-' prefix, but instead to consider them on a case-by-case basis. (That said, I don't disagree with what Tom=C3=A1s said about having "some vision as to which direction those renames should tend to, if one wants to have some overall consistency." And I agree with him that your proposal can serve discussion, and so is part of the process.) The functions in a library (especially 3rd-party) are a different story. They should have the library prefix, not some object-type prefix. E.g., if s.el functions were added to Elisp, and if the library prefix remained as `s-', then they should get that prefix. If the library prefix were renamed to `str-' or `foo' then that should be the prefix for its function names. But on its own, that has nothing to do with the type of objects the functions act on or return. The fact that most functions in that package might involve strings in some way is something else. Even a function, macro, etc. in it that has nothing to do with strings (if such exists) should get its library prefix. > yes, some generic functions will have trouble=C2=A0finding > a good home. ...those function could either be left > untouched, or they could be moved to `seq-`,... That's where the disagreement is, I think - wrt the degree to which such a renaming is needed or useful. Your point of view is apparently that functions should generally, i.e., by default, be prefixed with a thing name, and you acknowledge that it might be difficult for "some generic functions" to find a good thing type to name them with. My point of view is farther down the spectrum. It's not about generic functions. It's about many, probably MOST, functions in Lisp. They don't have a "good home" in the sense you mean it (some privileged object type), and IMO they shouldn't have a type-name prefix. IOW, you seem to want to repaint everything, but you acknowledge that it might be difficult to find the right color paint for some things. I don't. I think it makes more sense to paint only things that really need a type-labeling. I contrasted painting the bikeshed with patching holes in its roof. I suggested dealing with names case by case, and I even suggested filing bugs for that, to track, discuss, and debate case by case. A given case/bug could involve more than one function name. But I'd rather we err in the direction of too few at a time than too many. There's no right or wrong approach here. It's a question of aim, and view of the problem & cure. > But I suggest we don't talk about these corner cases See above. For you, the corner cases (to ignore) are a few "generic functions" that aren't easily assigned a thing type, and you propose to leave them out of the painting initiative. The corner cases for me are the relatively few functions whose names cry out for labeling as specific to some type, and I'd propose fixing their names, case by case.