dash.el
dash.el copied to clipboard
magnars
Discussion: should we merge with seq.el?
seq is now in emacs core and available to all, a move which we somehow failed to push for with dash.
It still only supports a rather small subset of dash functionaity, which is a reason I haven't adopted it yet (and likely never will until it is feature-compatible).
The move would require some effort but would solidify the emacs API, move the less-often-needed-but-really-nice-to-have functions into emacs proper, remove one dependency for great many packages, add support for multiple sequence types (granted we would have to reimplement some functions to work universally). Plus having one API instead of two is reason in itself I think. One problem that stands out to me immediately is how to deal with anaphora.
Magnar and I poured a lot of time into this project, but maybe it is time to integrate it and then phase it out eventually.
I would like to CC some people who I know depend (or did in the past, moving to seq in the meanwhile) and hear your opinions: @tarsius @rejeep @lunaryorn @bbatsov @nicferrier. If you know someone else who you think should have a say please invite them too.
I'm all for a "merger" of the projects. I believe that packages like seq and map are definitely the way to go (nothing beats less 3rd party deps), plus they are really clean and have great focused APIs. I've started moving away from dash.el in the projects I maintain a while back. I think many of the useful things that don't belong to seq and map can simply be stuffed into subr-x.el (I'd place there some of the s.el functions as well).
Frankly I don't think the anaphoras are that important, as they produce slightly confusing code for people not familiar with them. I used them a lot initially and then I simply stopped (even while I was still on dash).
//cc @malabarba
I think seq.el is a great initiative from @NicolasPetton. Dash was never going to be approved by emacs-devel, due to its cheeky namespace and weird anaphoras. So in my mind, seq is already the "dash in core" initiative. I quite like the anaphoras, but like @bbatsov I don't think they're very important. I also think they're unlikely to be included in core.
I think the best way forward for Emacs is to expand seq to include more of the dash features, moving towards phasing dash out. And in the meantime, dash will continue to be a bunch of helpful features that should have been in core but aren't there yet.
So far, whenever I proposed some sequence-related functionality to Nico, he was happy to accept it into seq.
As for the rest, I don't think the non-sequence functions/macros offered by dash should (or will) be added to seq. Maybe they can be added to subr-x, but I'm not even sure which are still missing so it's hard to say.
And I agree that the anaphoric macros are cute but rarely used.
Amen to what @magnars said.
(However I do like the anaphoras. Secretly I've been hoping for something like (mapcar #(cons %1 tail) values). That would make most of the anaphoras unnecessary. I think something like this was discussed on emacs-devel some time ago, but I don't know if anything came of it.)
I believe @abo-abo even offered an implementation for it, but people decided they preferred to add reader macros, so people could implement these things themselves.
Thank you for inviting me to this discussion. I feel honoured for your interest in my opinion.
I'm happily using both libraries, even together in the same project, and I like both. In Flycheck we generally prefer seq nowadays, but that's just to reduce dependencies, and we're still having a dash dependency anyways. To me both libraries appear mostly identical, but I don't use the anaphoras and won't allow their use in Flycheck because frankly I think they do more harm than they good, but I see why people like them, which brings me to my point:
I think it's great that we have the choice, and I'd not like to see that choice go away.
I'd love to still have a non-core list library that's open for everyone to contribute and doesn't require lengthy derailing discussions on emacs-devel for any little thing.
I think that there's no harm in having two, mildly competing libraries, one for the more conservative, and another more community driven, as long as both sides learn from each other and keep talking.
Please keep dash.
Anaphoras are funny thing, seems like we're roughly 50/50. Like @tarsius I like them quite a lot, especially when I prototype and I need to throw things together as fast as possible (often I then replace them with lambdas, especially if the forms get lengthy). The # syntax is interesting and maybe will partially solve the problem in the future.
As you say @lunaryorn , the community approach is the main reason I'm not completely sure. Getting things into emacs can be daunting, even if now it seems much easier than before (although since signing my papers two years ago I still haven't made a single contribution to emacs proper :/).
Dash for me is a lot like the hydrothermal vents where all sorts of mud and minerals and organic crap is mixed together to produce something nice in the end. Dash certainly feels out of place with some of its features, which came to be through organic accumulation of "nice features" which simply had no good home.
I think I will take some time to compile the most often used dash features in my projects and do a bit of research on how to possibly port them over to seq. I invite others to try to do the same (should be rather simple with grep and (-...) pattern or some such, we don't need to be 100% accurate).
Just to be clear. I most certainly don't think dash should be gone. Regardless of what is or isn't merged into seq or into core, dash should keep existing as it is and carrying the same features. And there are probably some features (like the anaphoras) that will never belong anywhere else.
So far, whenever I proposed some sequence-related functionality to Nico, he was happy to accept it into seq.
And I'd be happy to accept more of them.
Is there something specific that is missing in seq?
I'd love to see more dash functionality make it into the core, at the very least just bring dash as-is into ELPA, which should make the argument for pulling functions from it into seq.el easier, since they'd both be part of Emacs at that point.
We've done the assignment paperwork some time ago but I have to admit I forgot about it and merged a couple of patches that might not have been covered. Someone would have to go through that and then we should probably add some CA check to the pull requests because I tend to be quite trigger-happy when it comes to merging :/
When it comes to moving stuff into seq it would require complete reimplementation anyway because of how seq is handled (using generic methods), so having dash in ELPA shouldn't really be of much use there, I think.
The best way to do this would from my perspective be to simply start contributing dash functionality into seq directly. I wish it was developed through github :(
Matus Goljer [email protected] writes:
The best way to do this would from my perspective be to simply start contributing dash functionality into seq directly. I wish it was developed through github :(
It initially was, but since it was moved to Emacs's git repo, I stopped maintaining the GitHub repository.
You can however send me or the emacs-devel list patches, or even better submit them to Emacs' issue tracker.