"Thinking in types" or "The mind of a programmer"

[totherme]

In a previous post, pozorvlak and I wondered about the differences between the thought processes that goes into writing good static code, and those that go into good dynamic code. We figured that there wasn't a lot out there to help dynamic programmers get the hang of static style thinking, so what follows is a simple little toy example, solved in what I

Comments

[anonymous]

splitWith :: (a -> Bool)-> [a] ->[[a]]
splitWith fn lst =
case (break fn lst) of
(a, []) -> [a]
(a, b:cs) -> a : splitWith fn cs

split :: (Eq a) => a -> [a] -> [[a]]
split = splitWith . (==)
I knew break :: (a -> Bool) -> [a] -> ([a], [a]) from the Prelude, so I went looking for a way to recurse into the second element and drop its head (the match, traditionally dropped in a split). De-structuring pattern match looked the simplest.

[ari_rahikkala]

Just a couple of things I didn't mention in http://totherme.livejournal.com/3845.html?thread=13829#t13829 due to the comment character limit (exhaustion makes me tirelessly verbose

[totherme]

lol - you're right, I should have seen immediately that a split function would require Eq. But hey - I didn't, so I didn't want to pretend on-line that I did. Hopefully next time I need to write something like this, I'll spot the Eq and the resemblance to unfoldr right away :)

Thanks for the fold link - I'll take a look.

[pozorvlak]

I saw the type you gave to split and immediately knew you can't have enough experience of Haskell to be able to come up with an incredibly beautiful split :)

Well, speaking as someone who really doesn't have enough experience of Haskell, I found totherme's more detailed thought processes (and many of the comments here, including yours) to be more helpful than any number of "beautiful", impenetrable programs plucked whole from the skull of Zeus - Haskell has quite enough of those already :-)

That stack overflow page is great - thanks!