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: subr-x.el code and defsubst [was: Trimming strings, /.../subr-x.el modification] Date: Sat, 6 May 2017 11:07:31 -0700 (PDT) Message-ID: References: <87vapij1l7.fsf@holos> <6870A2B6-F685-4955-9C0A-256601DB47BC@gmail.com> <51D5E92C-F125-4ADE-8C55-E3513C00ECDC@gmail.com> <8F6958D6-3E13-4C31-B1F8-AF10A8FC8FC6@gmail.com> <0d4cb885-4bea-44d5-8a19-5b77773db563@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1494094103 15728 195.159.176.226 (6 May 2017 18:08:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 May 2017 18:08:23 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 06 20:08:18 2017 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 1d747t-00040U-Jl for ged-emacs-devel@m.gmane.org; Sat, 06 May 2017 20:08:17 +0200 Original-Received: from localhost ([::1]:52305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d747z-00049p-6L for ged-emacs-devel@m.gmane.org; Sat, 06 May 2017 14:08:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d747M-00049U-R8 for emacs-devel@gnu.org; Sat, 06 May 2017 14:07:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d747H-00069T-SC for emacs-devel@gnu.org; Sat, 06 May 2017 14:07:44 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:40120) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d747H-00066N-Hu for emacs-devel@gnu.org; Sat, 06 May 2017 14:07:39 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v46I7Z0t012100 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 6 May 2017 18:07:36 GMT 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 v46I7YEF004291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 6 May 2017 18:07:35 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v46I7XUJ032464; Sat, 6 May 2017 18:07:34 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 156.151.31.81 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:214629 Archived-At: > > The code will be byte-compiled. I see zero reason why these > > functions should be defsubsts. >=20 > The reason, AFAIC is the following: subr-x holds functions which we > haven't committed to adding to core. We exceptionally allow them to > not use a prefix but in return we only use subr-x while compiling (since > it's fundamentally not namespace-clean and we don't want to impose those > non-clean names upon the unsuspecting user). OK. Not a great reason, IMO, but I understand now, at least. I don't think that reason is obvious. Please consider adding a GIANT comment in subr-x.el to explain this exceptional treatment. This existing comment, which is all there is, does not cover it, IMO: ;; Less commonly used functions that complement basic APIs, often ;; implemented in C code (like hash-tables and strings), and are ;; not eligible for inclusion in subr.el. ;; Do not document these functions in the lispref. ;; http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01006.html And why is it that this library has still not been "committed to core"? (And isn't that what GNU ELPA is for?) Beyond that, this approach of not bothering with name prefixes, byte-compiling separately, etc. seems really weird (fragile, error prone). Why such an exception? Is this really the best way to handle code that you consider "experimental" or "less commonly used" or code "that complements basic APIs"?