At 14:11 29/07/04 +0200, Tomasz Zielonka wrote:
On Thu, Jul 29, 2004 at 01:57:51PM +0200, Marcin 'Qrczak' Kowalczyk wrote:
W li¶cie z czw, 29-07-2004, godz. 13:39 +0200, Tomasz Zielonka napisa³:
Have you looked at List.unfoldr? It's even more general.
unfoldr :: (b -> Maybe (a, b)) -> b -> [a]
And when we finally find a very general solution, the specific case of "split colon-separated fields" requires some thought and three lines of code using higher order functions and pattern matching, instead of just splitSep (== ':') line :-)
Make simple things easy, complex things possible. Concentrate on the first part. Generalize only if it doesn't make the common simple case harder. After all, one always can write a complex splitting function by hand. The simple version doesn't have to cover all possible generalizations, only those which don't disturb common cases.
I agree. I often found that writing a splitting function with unfoldr is a bit cumbersome.
So it appears. But how much is this due to the prelude/library functions not working together so well? Using the formulation of unfold from [1], some solutions appear a bit less cumbersome; e.g.: [[ unfold :: (b->Bool) -> (b->a) -> (b->b) -> b -> [a] unfold p f g x | p x = [] | otherwise = f x : unfold p f g (g x) splitBy p = unfold null (fst . break p) (tail . snd . break p) t1 = splitBy (==':') "ab:cde:fgh::ijk:" ]] The p and g functions can be tweaked to achieve the variations mentioned, though that's arguably getting as complicated as writing the required function to begin with. It does bother me that this formulation requires (in the example above) the 'break p' to be evaluated twice. I also note that none of the other functions offered have provided for the two use-cases I mentioned in [2], AFAICT. #g -- [1] http://web.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/index.html#... [2] http://www.haskell.org//pipermail/libraries/2004-July/002353.html ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact