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: subr-x.el code and defsubst [was: Trimming strings, /.../subr-x.el modification] Date: Sun, 14 May 2017 18:11:37 -0700 (PDT) Message-ID: <563f6898-f092-4369-af60-3e5c11e2b372@default> 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 1494810717 28891 195.159.176.226 (15 May 2017 01:11:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 May 2017 01:11:57 +0000 (UTC) Cc: Stefan Monnier , Emacs developers To: Tianxiang Xiong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 15 03:11:53 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 1dA4YB-0007P5-TO for ged-emacs-devel@m.gmane.org; Mon, 15 May 2017 03:11:52 +0200 Original-Received: from localhost ([::1]:34372 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dA4YH-0001MB-73 for ged-emacs-devel@m.gmane.org; Sun, 14 May 2017 21:11:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dA4Y8-0001M5-4A for emacs-devel@gnu.org; Sun, 14 May 2017 21:11:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dA4Y4-000670-TU for emacs-devel@gnu.org; Sun, 14 May 2017 21:11:48 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:48634) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dA4Y4-00066d-KA for emacs-devel@gnu.org; Sun, 14 May 2017 21:11:44 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4F1BerT007621 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 May 2017 01:11:41 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v4F1Bebs012785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 May 2017 01:11:40 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v4F1BdGZ015626; Mon, 15 May 2017 01:11:39 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: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 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:214851 Archived-At: > I also don't understand why `subr-x.el` exists.=C2=A0 > > First of all, why not put `string-*` functions in a `string.el`? > It's surprising that no such file exists at the moment. > > Secondly, why are these functions considered "experimental"? > If a package depends on a function in `subr-x` that is later > removed, is it any less inconvenient for the package author > than if `subr-x` was=C2=A0not=C2=A0experimental? No. Empirically, the > `string-*` and `thread-*` functions see a lot of use in the > wild, so (re)moving them at this point would cause quite an > uproar. > > If functions need to considered experimental, at least put > them in the "right" place--e.g. `string-empty-p` in `string.el`. > That way, even if the function's implementation needed to > be modified, package authors won't need to `require` a > different package. Organization matters. FWIW, I agree. Perhaps it's not a coincidence that this policy/approach was accompanied in time by the introduction (or perhaps increase) of the use of "*--*" names for "internal" Lisp constructs. Similarly misguided, I think. If you really feel the need for a "purgatory" or "lab" for code that you don't yet feel confident about or haven't yet consecrated as official or backed by commitment, code that you consider experimental or internal so that you can feel more freedom to modify it without worrying about users, at least stick it in GNU ELPA, please.