+1 to adding a single function that splits a list by a multi-element delimiter, e.g. the hypothetical
>>> *Data.List.split [a, b] [c, a, b, d, a, b, e, a]
[[c], [d], [e, a]]
The split package seems to heavyweight for base (I know I'd always have to look up the differences between splitOn, split, chop, and divvy), and more sophisticated needs should probably be filled by a special-purpose parser.
I would even say it might make sense to just restrict the function to Strings, unless there is widespread need for supporting Lists in general.
If and when base is split, then just include Data.List.Split with whatever package all the other List stuff gets put in. My point is, this module should live in the same package where the other list functions live.
I'm in favor of splitting base, but things should not be so broken up to the extreme of having a package just for left-pad. It is possible to find middle ground.
Ah in the context of splitting base this seems like a backward move. The solution must really be to have tooling that can pull in libraries with minimal friction.
On Fri, 2 Nov 2018, Dan Burton wrote:
> What about just adding Data.List.Split to base?
... and then splitting 'base'? :-)
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries