From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: "Alfred M. Szmidt" Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Sat, 09 May 2020 09:20:25 -0400 Message-ID: References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> <87wo5mc04t.fsf@fastmail.fm> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="82262"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joostkremers@fastmail.fm, rms@gnu.org, emacs-devel@gnu.org To: Philippe Vaucher Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 15:21:23 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 1jXPPv-000LFF-1B for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 15:21:23 +0200 Original-Received: from localhost ([::1]:34226 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXPPt-0006fP-HH for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 09:21:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXPP1-0005Hd-1u for emacs-devel@gnu.org; Sat, 09 May 2020 09:20:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51855) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXPP0-0002yY-Ol; Sat, 09 May 2020 09:20:26 -0400 Original-Received: from ams by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jXPOz-0004s3-4V; Sat, 09 May 2020 09:20:25 -0400 In-Reply-To: (message from Philippe Vaucher on Sat, 9 May 2020 14:05:28 +0200) 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:249423 Archived-At: > Richard, I think this is a good opportunity for you to actually go and > really see what dash.el is and also what s.el is, maybe even code a > little with them. Your comments really make it look like you vaguely > understand what they are about. I'm sorry if that's not the case. > > As someone who has gone through both, I still do not know what to use > dash.el for, I still don't see what s.el adds other than some more > Scheme like alises for the string functions in Emacs. I don't understand... is your point that dash.el/s.el would not be useful to you? Yeah sure, not all packages are useful for everyone. I cannot address both s.el and dash.el at the same time, they are two extremely different libraries that have nothing incommon. Lets please stop mixing them up as if they are the same. s.el has little point, it is thin wrappers around Emacs Lisp functions, and it has been explained why it isn't suitable (as is). dash.el is more interesting, but since that is not how you generally write Lisp (in general), it is hard for me to find something I'd use it for. And so far, nobody is willing to provide concrete examples on that topic and instead telling everyone to just go and read the code, I did -- still no clue what or how to use these functions in the context of Emacs Lisp. Can you give some examples of using dash.el? > Insisting on everyone to just sit down and understand 100K of code > (that is the size of dash.el), and then on top of it trying to find > something to use it for won't move the discussion forward. I'm not talking about reading the code, just the API. That is a very naive view of the matter. Lisp is one of the oldest high level programming languages that allow for higher order functions, s.el has nothing to do with that. dash.el adds interesting constructs that are available in other langugaes, and some might be interesting to add in Emacs Lisp. > Except if I missed it, here are the questions I didn't see an answer to: > > - As far as I know you are the only one who objected strongly against > s.el in ELPA (others please voice your opinion if you think like > Richard). > > I as a Emacs user would think s.el is a bad addition to ELPA -- it > doesn't add anything special, and makes code harder to read if people > use such constructs in the form that they are now, encouraging people > to use s-titleize instead of capitalize is going backwards, not > forwards. Well it'd be `s-capitalize` instead of `capitalize` but I think I understand your point, you think in terms of what the name is now how changing it is a burden. I think we disagree about what constitutes going forward but that's ok. Adding s.el to ELPA isn't about changing any names, they are two different topics. Renaming existing functions in Emacs is, and should be, a long process that shouldn't be done lightly. s-capitalize is something different, and unrelated to the Emacs Lisp function `capitalize'. s-capitalize does a downcase on all words except the first one, that is not the behaviour of `capitalize'. The corresponding function from s.el is s-titleize, which is a simple alias for `capitalize'. I picked this particular function because it is confusing to existing Emacs Lisp users, since its behaviour is entierly different. > So why this forceful insistance of adding a s.el? Why not try to make > Emacs as a whole better by suggesting the better parts of s.el that > can be added to Emacs, or finding functions that could be renamed? Well there isn't any forceful insistance of adding s.el to Emacs core as far as I know. There is an incomprehension about why not add it to ELPA, but it's more for ELPA's sake than mine. That is not true, it is exactly the opposite. See, https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00850.html Adding something to Emacs (be it Emacs or ELPA) has a bar, we shouldn't blindly add anything and everything. > - For most users, dash.el and s.el are very similar in nature. dash.el > is already in ELPA. If we refuse s.el, isn't it inconsistent? What > about the message we send? > > If these two libraries had only added, and not tried to redefine basic > Emacs Lisp, I think the discussion would have been quite different. > Encouraging people to use `s-titalize' instead of `capitalize' is a > net loss for all Emacs Lisp programmers. Again not the best example but ok. Please remember that what you see as a net loss is a net gain for most people used to high order programming discoverability. This again mixes a different matters, one of higher order functions and one of discoverability. Neither s.el or dash.el make Emacs lisp more discoverable. Adding a well design higher order function library is I'm sure something that would be welcome in Emacs. dash.el has some interesting functions for that, but could use better function names for them, and removing the trivial aliases would be a good start to maybe add them too Emacs (either via ELPA, or in Emacs proper). The objection here isn't what these libraries provide, but _how_ they provide it. As I mentioned before -- if these libraries would concentrate on extending, not replacing, Emacs Lisp it would be a different topic. Even the simple suggestion by RMS to call the library for clojure-lib or similar for functions that follow the semantics from Clojure would be vastly better. That makes it very clear that these are not functions that follow the Emacs Lisp style.