From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.devel Subject: Re: Imports / inclusion of s.el into Emacs Date: Fri, 1 May 2020 20:56:14 +0200 Message-ID: References: <266155d4-f9c0-8ed3-8df5-32feea171076@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000daf4e505a49abd76" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="78599"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 01 20:57:20 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 1jUaqd-000KKd-RI for ged-emacs-devel@m.gmane-mx.org; Fri, 01 May 2020 20:57:19 +0200 Original-Received: from localhost ([::1]:36280 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUaqc-0004VP-Rv for ged-emacs-devel@m.gmane-mx.org; Fri, 01 May 2020 14:57:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57098) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUaq3-0003pd-P1 for emacs-devel@gnu.org; Fri, 01 May 2020 14:56:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUaq3-0002LZ-0o for emacs-devel@gnu.org; Fri, 01 May 2020 14:56:43 -0400 Original-Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:35878) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jUaq2-0002K2-JP for emacs-devel@gnu.org; Fri, 01 May 2020 14:56:42 -0400 Original-Received: by mail-lj1-x22e.google.com with SMTP id u15so3502299ljd.3 for ; Fri, 01 May 2020 11:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lRcxBv/Rv1CL+T3RYptmiuEVjYdoyJ2eDj+kXHCTcSs=; b=UlmNy3gNywn/HIp/jxW0eHntvnHjFlH0zZEbWtrLw8ICC7IZVS7Wwvet8Ny+/W9DDH HwpTEMVAWNIMGEMxs3PT9fB3KVJWqptkvZkYZ23tI97nK2kHJ2pMDVo1Lw9nqHnLWfRW txw78D7gSdVFSGa9Q0AUMVTLPfVB9tdAjEhTZ5c1yuzRPKtp0nQ4+S+AJwFhvlpSPBa7 mK4ORw28SgJVAEPBrJddJwbBH/n2IrBW2t1EW0n4amcchezU6Bpgx7h74tllQ7IzEndv 6r7spS2ShoMVcJeK/QMXoeiV7u3mIJGNZIVhcoAAL8QsrgKOp2leuJHftvoYbTliMv/6 enRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lRcxBv/Rv1CL+T3RYptmiuEVjYdoyJ2eDj+kXHCTcSs=; b=uMmRKzEy2HzM6y7rHslvWNjmH5fuSukWX7SOSiEAwHZXNykLB9XzbrNkyfQUSXkI45 FCw4OKS3Bf8L+1PoIFUnqS2nlA5+Z5S3WrMKD29/6Ju6jnvY0f/tlSWeLFQUe9Fd/luC ISCqHR410p1qmgF7Qlj7Da3uGBTH/bxhMytPYAs0z95ZXBS+txZlMLJJ5rq25lCLNO1i HS41mmx750CCUzm0mq2oN33Ml14eR67NxCXT96kLvKchH/mVGElN/6aOsMfbMDp3FF/S 0wP7ewD8EVu2itZDBryX33IFs7bKwnU9J7ePwnpMyvNDTRPN3bjFOXoVBNwPpLsfQvgW JSEw== X-Gm-Message-State: AGi0PuaeltqanI0hCB1TuF+7HyOig/GXJ2nx1/6Y91vI1724vHe+fX3R 8fz4l+VrfCpL0n/UK6jL4o9l0fJ1yUCQb5BlFFVXc3C8Kfw= X-Google-Smtp-Source: APiQypK6NIJQhfVink4bEBFR/1/e7l6zmHdXgu4khasKouAN4E6Ta9O91YdG1y3I31E7q4MpF8QVntpyZZ/n5Fb8AtU= X-Received: by 2002:a2e:9e97:: with SMTP id f23mr3069985ljk.228.1588359400713; Fri, 01 May 2020 11:56:40 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::22e; envelope-from=philippe.vaucher@gmail.com; helo=mail-lj1-x22e.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2a00:1450:4864:20::22e 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:248339 Archived-At: --000000000000daf4e505a49abd76 Content-Type: text/plain; charset="UTF-8" > > > I never coded > > with clojure, but my argument for these helpers is that in code we do > > string manipulations all the time, they are trivial to write, so why not > > have trivial helpers. > > The criticism would be exactly the same: if they're trivial, why have > them in the library at all. > For me the reason would be: to focus on actual code instead of silly tasks like computing indices and making code more verbose than necessary also while avoiding silly bugs. > > I usually don't care about these extra > > function calls, what matters more to me is how beautiful the code looks > > and how readable it is. > > Often, I'd agree. But the tradeoffs when creating the standard library > of the language are somewhat different, IMHO. > Interesting point. I want to believe that we can have convenience without sacrificing performance, maybe by coding these in C? Just a thought, not an actual proposal. > > From your side, I understand that your definition of the minimal set is > > much thiner, and maybe what would help is to give the complete list of > > the functions you find superfluous and why (list at > > https://github.com/magnars/s.el so far you mention `s-prepend` and > > `s-append`). For example I'd disagree if you said `s-left` and `s-right` > > are not useful to import because it can be done with `substring`. > > > I will respectfully refuse this invitation: I have other work to do. No worries. I think I now have enough information to propose something concrete. Thanks for your input! --000000000000daf4e505a49abd76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I never coded
> with clojure, but my argument for these helpers is that in code we do =
> string manipulations all the time, they are trivial to write, so why n= ot
> have trivial helpers.

The criticism would be exactly the same: if they're trivial, why have <= br> them in the library at all.

For me the = reason would be: to focus on actual code instead of silly tasks like comput= ing indices and making code more verbose than necessary also while avoiding= silly bugs.

=C2=A0
> I usually don't care about these extra > function calls, what matters more to me is how beautiful the code look= s
> and how readable it is.

Often, I'd agree. But the tradeoffs when creating the standard library =
of the language are somewhat different, IMHO.

Interesting point. I want to believe that we can have convenience wi= thout sacrificing performance, maybe by coding these in C? Just a thought, = not an actual proposal.

=C2=A0
> > =C2= =A0From your side, I understand that your definition of the minimal set is<= br>> > much thiner, and maybe what would help is to give the complete= list of
> > the functions you find superfluous and why (list at> > https://github.com/= magnars/s.el so far you mention `s-prepend` and
> > `s-append`= ). For example I'd disagree if you said `s-left` and `s-right`
> = > are not useful to import because it can be done with `substring`.
&= gt;
>
> I will respectfully refuse this invitation: I have othe= r work to do.

No worries. I think I= now have enough information to propose something concrete.

Thanks for your input= !
--000000000000daf4e505a49abd76--