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: Mon, 4 May 2020 10:19:02 -0700 (PDT) Message-ID: <3df43231-ea25-4ceb-82f3-45a493091849@default> References: <83368ivmym.fsf@gnu.org> <5f91c6e5-b4af-4478-b221-4ca37f0fb74c@default> <2afdde98-4d71-4847-8ee4-b0eee677baef@default> <8d649ffd-c60e-4cb5-ae21-413cc39ae409@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="40538"; 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 Mon May 04 19:21:29 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 1jVemX-000AQZ-Ib for ged-emacs-devel@m.gmane-mx.org; Mon, 04 May 2020 19:21:29 +0200 Original-Received: from localhost ([::1]:33232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVemW-0005vi-KV for ged-emacs-devel@m.gmane-mx.org; Mon, 04 May 2020 13:21:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54512) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVekH-0002aV-As for emacs-devel@gnu.org; Mon, 04 May 2020 13:19:09 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:49580) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVekG-0003HX-05; Mon, 04 May 2020 13:19:08 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 044HHlbn092014; Mon, 4 May 2020 17:19:05 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=WYsUhE7/LdQqzQtSbBCytG8q7bjJweXtrxm0wq5LaCs=; b=QuMiIcrl2qTBGBGR02qGhWRurIiW41gNJ/frBHXzne8Br22OxWhcCYFoIvi0hqilZj6C Leo+sHVBJY9KJPpglYsh39PH96KxDEMjQgUkFP92ypi0hye4ygmQ3sDyddu/pbIW7Qjr bFSqk1dPSBq0t+rrnQaXyPruC4aFkKy8jfsbNvV1nQxjip4qk9/C7lKBy2v0Klhf6TNy x2Md2tl/nvC1d9N9JCHgrJQioyQF0EF848o4STenCMHedyOYvjP8xtTfGr90qbvdlkN+ +TX6nAxrKZUgHeWAYxrC24DHlkT7CEy1a0NFfxAeetx4rKU2eaP1goNj1ejA5tOczCxK JA== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 30s1gn031q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 04 May 2020 17:19:05 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 044HIVrM019078; Mon, 4 May 2020 17:19:04 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 30sjjwaxvx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 04 May 2020 17:19:04 +0000 Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 044HJ3xm030773; Mon, 4 May 2020 17:19:03 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 suspectscore=0 mlxscore=0 phishscore=0 bulkscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005040137 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9610 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 mlxscore=0 spamscore=0 clxscore=1015 priorityscore=1501 bulkscore=0 phishscore=0 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005040137 Received-SPF: pass client-ip=156.151.31.85; envelope-from=drew.adams@oracle.com; helo=userp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/04 12:04:14 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_H2=-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:248876 Archived-At: >> It can make [more] 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. > > Just to be clear, "type-grouping" you more or less see > the point but "topic-grouping" (e.g regexp, string) > not so much? No. I was distinguishing the definition of an abstract data type, and the function definitions needed for that, as a more focused kind of grouping from grouping functions just by the type of an argument or the return value. In OOP, a function that merely uses an object in a given class is often required to itself be a method of that class. That's not so for other kinds of programming, and it's not so, in general, for formal definition of ADTs. >> Most functions do not fit that bill of defining a >> thing type.=C2=A0 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.=C2=A0 Perhaps there are some >> cases in Elisp where it would make sense to prefix >> more functions that involve a particular kind of >> thing.=C2=A0 I've acknowledged that.=C2=A0 And others have >> said the same thing, citing strings as a type that >> might be looked at more in this regard. > > Okay, but I think we already agree on this? Not so sure. If so, good. > I propose to alias/rename functions where it's > "obvious", but as we saw that what is obvious for > me is not obvious for everyone, so that's > complicated. Yes. And I'm guessing that the more you think about it, the more you might find that some of what you thought was obvious is not quite so straightforward. Just a thought. In some of what you wrote, you seemed to think that your background of having worked with many languages etc. made things obvious to you, and that others might not have such a rich background and so they don't see easily the light. You might be surprised that some here also have long and rich backgrounds with many languages. That they might not agree with you - might not see what you see as "obvious" - might not mean what you think. > I think we reached a point where everything > proposed was rejected so this is a dead end. I haven't seen a clear proposal. And I don't know that anything has been rejected. The discussion has been rather mixed and somewhat unclear, IMO. I don't think anyone has rejected the idea of renaming some functions or aliases them to new names. The devil is in the details. I suggested that any proposed name changes (including aliases) be submitted (and tracked) as bug/enhancement requests. > > 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. > > The ones I proposed were all rejected :-/ Do you > have one in mind? No, not at the moment. And I'm not aware that anything has been rejected. If you submit them as a bug report (or bug reports, if they're not very related) then it will be clear if the bug gets fixed, stalls, or is closed as won't fix.