Today yet another newbie in #haskell asked about a 'split' function for lists, and I got fed up with saying 'no one can agree on the right interface so it doesn't exist, just write it yourself', because it's a really dumb answer, even if it's true. Instead of trying to get a 'split' function added to Data.List (which will never ever happen), I thought, why not create a module Data.List.Split which contains implementations of every conceivable way to split a list? Of course, people will probably still argue over what should go in such a module, what to name the various functions, etc., but hopefully we can converge on something useful. I've created a Data.List.Split page on the wiki: http://haskell.org/haskellwiki/Data.List.Split Please add code to it! Once something useful is hashed out we can upload it to hackage. Perhaps eventually some of it can be folded into the standard libraries, but this seems like a much more lightweight way to get started. -Brent
A very nice initiative I must say; although the page should contain
the usual explanation for why such a split method can't be universal.
That is, add the same explanation you give every time; but to the
page.
/Gianfranco
On Sat, Dec 13, 2008 at 5:30 PM, Brent Yorgey
Today yet another newbie in #haskell asked about a 'split' function for lists, and I got fed up with saying 'no one can agree on the right interface so it doesn't exist, just write it yourself', because it's a really dumb answer, even if it's true.
Instead of trying to get a 'split' function added to Data.List (which will never ever happen), I thought, why not create a module Data.List.Split which contains implementations of every conceivable way to split a list? Of course, people will probably still argue over what should go in such a module, what to name the various functions, etc., but hopefully we can converge on something useful.
I've created a Data.List.Split page on the wiki:
http://haskell.org/haskellwiki/Data.List.Split
Please add code to it! Once something useful is hashed out we can upload it to hackage. Perhaps eventually some of it can be folded into the standard libraries, but this seems like a much more lightweight way to get started.
-Brent _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Patience is the last resort for those unable to take action
On Sat, Dec 13, 2008 at 05:39:55PM +0100, Gianfranco Alongi wrote:
A very nice initiative I must say; although the page should contain the usual explanation for why such a split method can't be universal. That is, add the same explanation you give every time; but to the page.
Good idea; I've added a list of possible ways to split, both to give people ideas for code to write, and to demonstrate why it's impossible to come up with one 'best' split function. vixey has already added some code, but we need more! -Brent
I have actually been thinking about a similar thing, but on the "group" subject.
One can actually group things in many ways, such as groupBy (==) , so
that groupBy (==) [1,2,1,2] should give
[[1,1],[2,2]]. Of course other ideas are possible.
On Sat, Dec 13, 2008 at 5:47 PM, Brent Yorgey
On Sat, Dec 13, 2008 at 05:39:55PM +0100, Gianfranco Alongi wrote:
A very nice initiative I must say; although the page should contain the usual explanation for why such a split method can't be universal. That is, add the same explanation you give every time; but to the page.
Good idea; I've added a list of possible ways to split, both to give people ideas for code to write, and to demonstrate why it's impossible to come up with one 'best' split function.
vixey has already added some code, but we need more!
-Brent _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Patience is the last resort for those unable to take action
* On Saturday, December 13 2008, Gianfranco Alongi wrote:
I have actually been thinking about a similar thing, but on the "group" subject. One can actually group things in many ways, such as groupBy (==) , so that groupBy (==) [1,2,1,2] should give [[1,1],[2,2]]. Of course other ideas are possible.
That result happens with:
sortedGroups = group . sort
That composition is pretty, unlike those splitting functions. I don't know if manually fusing sort and group helps performance at all though. Making groups by comparing with the previous element, or the first element of the current group is occasionally useful: (this does the former)
groupIncDiff :: (a -> a -> Bool) -> [a] -> [[a]] groupIncDiff p = uncurry (:) . foldr w ([],[]) where w n ([],a) = ([n],a) w n ((x:xs),a) | p x n = (n:x:xs,a) | otherwise = ([n],(x:xs):a)
(in case somebody feels like assembling the apparently numerous was to group) On another note, is there much use of such simple library functions: does concatMap, for instance, save anything other than a couple parantheses, or does (concat . map) not necessarily get optimized into the same thing? Adam
On Sun, 2008-12-14 at 00:35 -0500, Adam Vogt wrote:
On another note, is there much use of such simple library functions: does concatMap, for instance, save anything other than a couple parantheses, or does (concat . map) not necessarily get optimized into the same thing
Bart Massey’s results suggest very little difference: http://wiki.cs.pdx.edu/forge/concatmap.html (Yellow blobs + green crosses.) - George
On Sun, 2008-12-14 at 19:46 +1300, George Pollard wrote:
On Sun, 2008-12-14 at 00:35 -0500, Adam Vogt wrote:
On another note, is there much use of such simple library functions: does concatMap, for instance, save anything other than a couple parantheses, or does (concat . map) not necessarily get optimized into the same thing
Bart Massey’s results suggest very little difference: http://wiki.cs.pdx.edu/forge/concatmap.html
(Yellow blobs + green crosses.)
I should have said that, on the other hand, with stream fusion enabled, (concat . map) outperforms (concatMap) :) - George
On Mon, 2008-12-15 at 08:40 +0000, Neil Mitchell wrote:
That can only be a bug in stream fusion - concatMap should always be prefered!
Yes, but it is unclear from the article whether the concatMap (w/ stream fusion enabled) is Data.List.Stream's concatMap or the Prelude's concatMap. It's only a bug in the former case :) - George
Adam Vogt wrote:
* On Saturday, December 13 2008, Gianfranco Alongi wrote:
I have actually been thinking about a similar thing, but on the "group" subject. One can actually group things in many ways, such as groupBy (==) , so that groupBy (==) [1,2,1,2] should give [[1,1],[2,2]]. Of course other ideas are possible.
That result happens with:
sortedGroups = group . sort
That composition is pretty, unlike those splitting functions. I don't know if manually fusing sort and group helps performance at all though.
Sorting requires an Ord instance, though. Here's a relatively simple but slow way which doesn't: fullGroupBy :: (a -> a -> Bool) -> [a] -> [[a]] fullGroupBy rel xs = map (\a -> filter (rel a) xs) (nubBy rel xs)
participants (6)
-
Adam Vogt -
Brent Yorgey -
George Pollard -
Gianfranco Alongi -
Matti Niemenmaa -
Neil Mitchell