Including some functions from dash.el in Emacs?

Including some functions from dash.el in Emacs?

[Nicolas Petton]

Hi,

When manipulating lists I often needs some basic list functions provided
by dash.el[1] and missing from builtin Elisp functions. Some are
implemented one way or another in cl-lib, some are just missing, but I
think it would be great if Elisp had them builtin, like `flatten`,
`filter` or `reduce`.

Would it make sense to include some of the dash.el functions into Emacs?
It wouldn't have to be all of them, but including some basic ones would
IMO be a big plus.

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

Re: Including some functions from dash.el in Emacs?

[Stefan Monnier]

> think it would be great if Elisp had them builtin, like `flatten`,
> `filter` or `reduce`.

IIUC, `filter' is covered by `cl-remove-if`, and `reduce' is called
`cl-reduce', right?

As for `flatten', all the examples I've seen where it's used have been
either cases where I think that using a different structure would have
made simpler&clearer code (and removed the need for `flatten'), or where
you really really got lucky.

If you think about types, flatten can't make sense for lists (since
lists are typically "lists of <something>" but not "list of list of list
of list of list ..."), so it is only really useful for trees where it
gives you the in-order elements of the tree, so it only works for trees
with no extra meta info.  In those tree cases, I believe that
a tree-traversal-iterator would be more useful.

> Would it make sense to include some of the dash.el functions into Emacs?

I'm in the process of trying to get dash.el included in GNU ELPA.
I haven't decided yet whether or when it should go into Emacs or stay
in GNU ELPA.


        Stefan

Re: Including some functions from dash.el in Emacs?

[Rasmus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> think it would be great if Elisp had them builtin, like `flatten`,
>> `filter` or `reduce`.
>
> IIUC, `filter' is covered by `cl-remove-if`, and `reduce' is called
> `cl-reduce', right?

Related is also cl-remove-if-not.

>> Would it make sense to include some of the dash.el functions into Emacs?
>
> I'm in the process of trying to get dash.el included in GNU ELPA.
> I haven't decided yet whether or when it should go into Emacs or stay
> in GNU ELPA.

Thanks Stefan, that's super cool!

—Rasmus

-- 
With monopolies the cake is a lie!

Re: Including some functions from dash.el in Emacs?

[Nicolas Petton]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> think it would be great if Elisp had them builtin, like `flatten`,
>> `filter` or `reduce`.
>
> IIUC, `filter' is covered by `cl-remove-if`, and `reduce' is called
> `cl-reduce', right?

Indeed, but I thought that having it builtin (ie no cl-lib
required) would make Elisp better. Maybe that's just me but I always see
cl-lib as a compatibility layer for CL, not something that I should
almost always load in order to have decent manipulation list functions.

Cheers,
Nico

>
> As for `flatten', all the examples I've seen where it's used have been
> either cases where I think that using a different structure would have
> made simpler&clearer code (and removed the need for `flatten'), or where
> you really really got lucky.
>
> If you think about types, flatten can't make sense for lists (since
> lists are typically "lists of <something>" but not "list of list of list
> of list of list ..."), so it is only really useful for trees where it
> gives you the in-order elements of the tree, so it only works for trees
> with no extra meta info.  In those tree cases, I believe that
> a tree-traversal-iterator would be more useful.
>
>> Would it make sense to include some of the dash.el functions into Emacs?
>
> I'm in the process of trying to get dash.el included in GNU ELPA.
> I haven't decided yet whether or when it should go into Emacs or stay
> in GNU ELPA.
>
>
>         Stefan

-- 
Nicolas Petton
http://nicolas-petton.fr

Re: Including some functions from dash.el in Emacs?

[Stefan Monnier]

> Indeed, but I thought that having it builtin (ie no cl-lib
> required) would make Elisp better. Maybe that's just me but I always see
> cl-lib as a compatibility layer for CL, not something that I should
> almost always load in order to have decent manipulation list functions.

The problem is only in your mind.  Adding "(require 'cl-lib)" to the
beginning of your file costs only 18bytes.  I think you can afford it.


        Stefan

Re: Including some functions from dash.el in Emacs?

[Nicolas Petton]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Indeed, but I thought that having it builtin (ie no cl-lib
>> required) would make Elisp better. Maybe that's just me but I always see
>> cl-lib as a compatibility layer for CL, not something that I should
>> almost always load in order to have decent manipulation list functions.
>
> The problem is only in your mind.  Adding "(require 'cl-lib)" to the
> beginning of your file costs only 18bytes.  I think you can afford it.
>

Adding (require 'cl-lib) doesn't cost much, you are right, but IMHO it
has nothing to do with the cost.

I asked about dash functions because I personally think that Elisp would
be much better with such list manipulation functions builtin.

I think that using cl-lib only to filter a list shows that something is
missing from the language. To me it is also weird to use prefixed
functions for basic features like "cl-remove-if" and "cl-reduce".

Please understand that I'm only willing to understand the reason behind
this and why adding some of this functions wouldn't modernize and
improve Elisp.

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

Re: Including some functions from dash.el in Emacs?

[Stefan Monnier]

> I think that using cl-lib only to filter a list shows that something is
> missing from the language.  To me it is also weird to use prefixed
> functions for basic features like "cl-remove-if" and "cl-reduce".

The real problem indeed is one of naming and coherence.
It would be nice to group all list functions under the "list-" prefix,
for example.

The main benefit I see of the dash.el library is that it tries to
provide a coherent set of names (and functionality).

But it falls into the trap of having a "too attractive" very short
prefix, so it goes on and adds things unrelated to lists (e.g. the
threading macros, the when-lets, the function combinators).

> Please understand that I'm only willing to understand the reason behind
> this and why adding some of this functions wouldn't modernize and
> improve Elisp.

Just because something has existed for a long time doesn't mean it's
bad, so "modernizing" is pretty low on my priority list.

But yes, Elisp's "core" functions suffer from lots of irregularities,
and getting rid of them would be an improvement.  E.g.:
- Merging the various `get', `window-parameter', `process-get', ...
- Merge nth, aref, and elt.
- Group related functions under one prefix (e.g. for lists).


        Stefan

Re: Including some functions from dash.el in Emacs?

[Nicolas Petton]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I think that using cl-lib only to filter a list shows that something is
>> missing from the language.  To me it is also weird to use prefixed
>> functions for basic features like "cl-remove-if" and "cl-reduce".
>
> The real problem indeed is one of naming and coherence.
> It would be nice to group all list functions under the "list-" prefix,
> for example.

Then another question arises, where to start and stop? I would hate
having "list-car" for instance, and "mapcar" can take any sequence.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

Re: Including some functions from dash.el in Emacs?

[Stefan Monnier]

>> The real problem indeed is one of naming and coherence.  It would be
>> nice to group all list functions under the "list-" prefix,
>> for example.
> Then another question arises, where to start and stop? I would hate
> having "list-car" for instance, and "mapcar" can take any sequence.

Aahh, choices!


        Stefan

Re: Including some functions from dash.el in Emacs?

[raman]

On balance, I agree re the comments on flatten. That said, if dash is
integrated in, I would prefer to see it bundled -- if it's on elpa, I
still cant use that functionality in a package like Emacspeak since the
user would have to first pull dash from elpa before getting Emacspeak
going, which in my opinion would be an undue burden.

Re: Including some functions from dash.el in Emacs?

[Stefan Monnier]

> On balance, I agree re the comments on flatten. That said, if dash is
> integrated in, I would prefer to see it bundled -- if it's on elpa, I
> still cant use that functionality in a package like Emacspeak since the
> user would have to first pull dash from elpa before getting Emacspeak
> going, which in my opinion would be an undue burden.

That's easy to solve: if the user installs emacspeak via package.el,
dash.el will be installed by package.el automatically.


        Stefan

Re: Including some functions from dash.el in Emacs?

[raman]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
Sadly Not Yet at least, since elpa doesn't make it easy for me (or at
least I dont know how) to  bundle the speech server which might need
compilation (not elisp)     >> On balance, I agree re the comments on flatten. That said, if
    >> dash is integrated in, I would prefer to see it bundled -- if
    >> it's on elpa, I still cant use that functionality in a package
    >> like Emacspeak since the user would have to first pull dash from
    >> elpa before getting Emacspeak going, which in my opinion would be
    >> an undue burden.
    Stefan> 
    Stefan> That's easy to solve: if the user installs emacspeak via
    Stefan> package.el, dash.el will be installed by package.el
    Stefan> automatically.
    Stefan> 
    Stefan> 
    Stefan>         Stefan

Compiling non-Elisp files in ELPA packages (was: Including some functions from dash.el in Emacs?)

[Stefan Monnier]

> Sadly Not Yet at least, since elpa doesn't make it easy for me (or at
> least I dont know how) to  bundle the speech server which might need
> compilation (not elisp)

ELPA currently doesn't support such things, indeed, and since this is
something that's needed by several "potential packages", it would be
good to fix this and provide support for it.  So I encourage you to try
and see what would be needed and help us improve package.el in
that direction.

This said, in the mean time, you might get things to work by adding in
the main Elisp file of your package something along the lines of:

    (eval-when-compile (call-process "make"))


-- Stefan