Proposal for Data.List.splitBy

Marcus D. Gabriel marcus at
Mon Jan 19 15:45:38 EST 2009

Brent Yorgey wrote:
> Not really. You are welcome to look at the source of
> Data.List.Split.Internals yourself;

Fair enough, I will look at it.

> Let me be clear---I am not against adding some splitting functions to
> Data.List, if consensus as to what these functions should be is
> reached.

Not to worry, this was clear to me.  I am sorry if my thread obscured this.

> If I were to write
> organizeBy :: ([a] -> Bool) -> [a] -> [([a], [a])]
> could you think of a specification such that this function
> would be a work horse in implementing Data.List.Split.Internals
> and Data.List.Split?
> I could, but I think the result would be rather uglier and harder to
> understand than the current implementation.

I understand.  I do not perceive that I have expressed very well the way
that I am trying to conceptualise of this, but the observation of yours
above makes me conclude that adding a few splitter functions to
Data.List would just be arbitrary.  (Alex already stated this point of

> Finally, this whole thread brings up the question in my mind
> about module design.  As work is put into Data.List.Split, what
> is the guiding principle that prevents it from becoming
> Data.List.Extensions or to be a bit more direct,
> Data.List.TheFunctionsThatWereForgotten?
> Are you serious?

Well, actually yes, I was serious, but see below.

> It seems quite clear to me that Data.List.Split will
> *not* turn into that.  For one thing, it contains only list-splitting
> functions; for another thing, I do not foresee putting that much more
> work into it.

Ok, I was on a tangent.  Given this above, no, I was not serious.

> A theoretical module which contains implementations/combinators for
> implementing every possible method of list-splitting known to man.
> This way no one has to argue about what the correct interface for
> split is, we can just have them all. 
>> Is not this Data.List?  In other words, what idea or theme does
>> a new Haskell programmer use to decide to first look into Data.List
>> as opposed to Data.List.Split and vice versa?
> I was being sort of facetious in that quote. =)

Ok, once again, I was on a tangent and drifting off topic.  In my
defence, my parents-in-law were here for my Son's birthday which in
Alsace means a lot of good food and wine which also means I should not
write e-mails at night after such an event :).


So, to conclude, when I first started using Haskell 98, at one point in
time I was looking for some splitter idioms in the List module.  The
functions break and span were close, but not it.  The functions

> lines :: String -> [String]
> unlines :: [String] -> String
> words :: String -> [String]
> unwords :: [String] -> String

seemed out of place compared to everything else in the List module just
because of their type signature whereupon it seemed even more odd that I
could not just split /etc/passwd or /etc/group on ':' with something
directly suited to the task that was in the List module as an example.

Thanks for the thread,
- Marcus

  Marcus D. Gabriel, Ph.D.                         Saint Louis, FRANCE            mailto:marcus at

More information about the Libraries mailing list