From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Tianxiang Xiong Newsgroups: gmane.emacs.devel Subject: Re: subr-x.el code and defsubst [was: Trimming strings, /.../subr-x.el modification] Date: Sun, 14 May 2017 15:45:11 -0700 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: multipart/alternative; boundary="94eb2c06d05af791e3054f83b05a" X-Trace: blaine.gmane.org 1494801958 12619 195.159.176.226 (14 May 2017 22:45:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 May 2017 22:45:58 +0000 (UTC) Cc: Stefan Monnier , Emacs developers To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 15 00:45:50 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 1dA2Gs-000375-Ed for ged-emacs-devel@m.gmane.org; Mon, 15 May 2017 00:45:50 +0200 Original-Received: from localhost ([::1]:34106 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dA2Gx-0006WG-RL for ged-emacs-devel@m.gmane.org; Sun, 14 May 2017 18:45:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dA2GI-0006WB-VO for emacs-devel@gnu.org; Sun, 14 May 2017 18:45:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dA2GH-0007G9-1E for emacs-devel@gnu.org; Sun, 14 May 2017 18:45:14 -0400 Original-Received: from mail-yb0-x233.google.com ([2607:f8b0:4002:c09::233]:36788) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dA2GG-0007FI-Pc for emacs-devel@gnu.org; Sun, 14 May 2017 18:45:12 -0400 Original-Received: by mail-yb0-x233.google.com with SMTP id s22so23629308ybe.3 for ; Sun, 14 May 2017 15:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hC5eJJXyc1mhip2D/etu65BpTyrgOH6nWmLDIyaIF/Q=; b=CJLkBabkjuJ830sQL8C9d40lcozguHZRHCSbXBpNIT0c6A9+1N6MUmw+NvzWwrARCx pBQgjLfLP19h6YUX7VFFY+vrY3W0fVKok1PgMnoTGztmko9rXJe73D7fHnMfYVDrL56m nKYlYAvpYMhsp14nzUBNmen+L0LGLB373lNz3cO28Ipz625lsg1o1dErqQZo3S7OUc2k FQwYvvABv+2b78S35ckPU9qtS7ojb8yD2xxFADOvIIXxN0qiLLVsznCqFZw72Y6I+x0K i8lQsEK6PuSHcBGGvMcf+e6TRN8CExe1ds9Uz4zPoHSKbMoEn48i2HPpmCARK11pyw2m D+Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hC5eJJXyc1mhip2D/etu65BpTyrgOH6nWmLDIyaIF/Q=; b=aTF47nesFSPBXcwuQ+F/Ow6wkqBowa9inK0GGkIvFFFjumlzG4VeXlu75C97yoEy1W tnep70E5Qnb3HdFOwu4khTknMaEzTQJKqYrj5wSUr6kcMoqbjMgyBZSAF0oRU1qNvuG9 NI2DqxV9jDFkZf6c/7+yY1SLZnsrKrq5yKjZyIQ8uT+m43uDGWv0Abn6TMFhhxiBohxp CCPk5uLg6yaevy7X3dmAugGzxPup6Hjehz+klygLTHsaRPsJLCyZkzWwY18fWg429IAI eIXaZsSp91z1M5U6Od/fV37qdZWt1sABbbJ4lHygqKojZxjfPdlQl17EsaMcEZxzTHPs RaNA== X-Gm-Message-State: AODbwcALZHRSvHbWReLZGRXauiZzD2WHgAsiJ0DyZ5l0WwWIHr2XEK5/ xNxsUC9PCQjjWDP/MwUUtzWNqcTLpA== X-Received: by 10.37.215.1 with SMTP id o1mr2670619ybg.79.1494801911876; Sun, 14 May 2017 15:45:11 -0700 (PDT) Original-Received: by 10.13.232.22 with HTTP; Sun, 14 May 2017 15:45:11 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4002:c09::233 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:214848 Archived-At: --94eb2c06d05af791e3054f83b05a Content-Type: text/plain; charset="UTF-8" I also don't understand why `subr-x.el` exists. 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 *not* experimental? 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. On Sat, May 6, 2017 at 11:07 AM, Drew Adams wrote: > > > The code will be byte-compiled. I see zero reason why these > > > functions should be defsubsts. > > > > 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"? > > --94eb2c06d05af791e3054f83b05a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also don't understand why `subr-x.el` exists.=C2=A0<= div>
First of all, why not put `string-*` functions in a `str= ing.el`? It's surprising that no such file exists at the moment.
<= div>
Secondly, why are these functions considered "exper= imental"? 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-*` a= nd `thread-*` functions see a lot of use in the wild, so (re)moving them at= this point would cause quite an uproar.

If functi= ons need to considered experimental, at least put them in the "right&q= uot; place--e.g. `string-empty-p` in `string.el`. That way, even if the fun= ction's implementation needed to be modified, package authors won't= need to `require` a different package. Organization matters.

On S= at, May 6, 2017 at 11:07 AM, Drew Adams <drew.adams@oracle.com>= wrote:
> > The code will be= byte-compiled.=C2=A0 I see zero reason why these
> > functions should be defsubsts.
>
> The reason, AFAIC is the following: subr-x holds functions which we > haven't committed to adding to core.=C2=A0 We exceptionally allow = them to
> not use a prefix but in return we only use subr-x while compiling (sin= ce
> it's fundamentally not namespace-clean and we don't want to im= pose those
> non-clean names upon the unsuspecting user).

OK.=C2=A0 Not a great reason, IMO, but I understand now, at least.

I don't think that reason is obvious.=C2=A0 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/<= wbr>html/emacs-devel/2014-01/msg01006.html

And why is it that this library has still not been "committed to
core"?=C2=A0 (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).=C2=A0 Why such an exception?=C2=A0 Is this really the best way to handle code that you consider "experimental" or "less common= ly used"
or code "that complements basic APIs"?


--94eb2c06d05af791e3054f83b05a--