From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: ams@gnu.org (Alfred M. Szmidt) Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Mon, 11 May 2020 01:49:45 -0400 Message-ID: References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> <87wo5mc04t.fsf@fastmail.fm> <835zd5h6tq.fsf@gnu.org> <87o8qwc88b.fsf@russet.org.uk> <85E41CCF-8D56-4878-95CA-4ED7A6B8E40B@icloud.com> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="75749"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joostkremers@fastmail.fm, emacs-devel@gnu.org, rms@gnu.org, phillip.lord@russet.org.uk To: pcr910303@icloud.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 11 07:50:18 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 1jY1KU-000JcO-Pb for ged-emacs-devel@m.gmane-mx.org; Mon, 11 May 2020 07:50:18 +0200 Original-Received: from localhost ([::1]:51702 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jY1KT-000501-Nv for ged-emacs-devel@m.gmane-mx.org; Mon, 11 May 2020 01:50:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59662) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jY1Jz-0004J7-Qf for emacs-devel@gnu.org; Mon, 11 May 2020 01:49:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57909) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jY1Jy-0002OG-Ts; Mon, 11 May 2020 01:49:46 -0400 Original-Received: from ams by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jY1Jx-00075S-Ce; Mon, 11 May 2020 01:49:45 -0400 In-reply-to: <85E41CCF-8D56-4878-95CA-4ED7A6B8E40B@icloud.com> (message from pcr910303@icloud.com on Mon, 11 May 2020 11:59:31 +0900) 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:249766 Archived-At: > 'clos-prepend' is not harder to read than 's-prepend'. The problem is that lots of packages use `s-prepend', rather than `clos-prepend'. There are too many packages that are blocked on being ELPA because of s.el and f.el (as dash.el is on ELPA). Then those packages should be modified to not use s.el/dash.el/f.el before they are included in ELPA. Just like that would be a requirement for them to be included in Emacs. s.el could be modified in such a way that it would have compiler warnings for the functins that Emacs Lisp already has, and where there are different semantics encourage to use the Emacs Lisp way of writting. The functions that do not have a equivalent could added in subr-x. Users would then, slowly, migrate their code, and make it easier to include things in ELPA in the future. This is just a matter of following the good practises that already exist in Emacs. It would be a bad idea to start making a mess, and then encouraging this mess to become larger.