emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]


From: Phillip Lord
Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]
Date: Mon, 11 May 2020 17:19:39 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.90 (gnu/linux)

address@hidden (Alfred M. Szmidt) writes:

>    > '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.


Posited on s.el being a mess, which neither it, nor dash.el is. They are
both nice APIs that are nice to use.

I did manage to drop a dash.el dependency form one of my libraries and
replace it with seq.el. That worked because it was close to a drop
in. But people have already chosen to work with dash, or s, or f, even
though it means adding a dependency because they are nice.

Phil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]