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

[Philippe Vaucher <philippe.vaucher@gmail.com>]

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

To me it has the point of discoverability. I understand it's not your
position. I think both positions are reasonable.


> 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?

Sure! I takes a bit of time to construct these so they'll come in a
separate email.


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

FTR, I'm not saying high order programming is possible thanks to
dash.el, I'm saying dash.el follows the "conventions" ones expect a
high order programming language to use. It's probably not so much
about the exact names but more about the grouping (namespaces) which
makes it easy to "guess" or "look for" a similar name that you already
know.


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

Got me there! See, this is a good example: in clojure, ruby, python
and I'm sure other languages too "capitalize" means "downcase the
whole string but upcase the first character".
Emacs's `capitalize` is usually absent from other languages, but when
it exists it's named titleize (Ruby).

I can see how wanting to rename capitalize to titleize makes people
cry from the Emacs lisp perspective and how it feels silly from the
"rest of the languages" perspective (that you have "titleize" but not
"capitalize").


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

Hum. Let's try to unify our vision by saying: it does not make the
current Emacs core lisp functions a lot more discoverable, but for a
significant number of people it'd allow them to quickly "understand"
how to do things and code packages and thus increase the overall
productivity ?

Also personnaly when I want to know how to do something in plain Emacs
lisp I go & look at the source of dash functions, so in a sense it
improves "plain Emacs lisp" discoverability for me.


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

You made yourself very clear, thanks for the summary.

Philippe