When you think about it, what you are saying is that Haskell programmers shouldn't take advantage of the extra tools that Haskell provides.
No, I'm not saying this.
But, as an example, when you read a function like:
buildPartitions xs ns = zipWith take ns . init $ scanl (flip drop) xs ns
that can be rewritten (argument reversed) as:
takeList :: [Int] -> [a] -> [[a]] takeList [] _ = [] takeList _ [] = [] takeList (n : ns) xs = head : takeList ns tail where (head, tail) = splitAt n xs
I think this is a perfect example. Haskell allows you to abstract out the concepts of recursion, zipping and iteration. Your alternative reproduces these explicitely and intermixes them. You are saying that programmers should avoid using these higher level abstractions and instead fall back to more explicit constructs that are, for you, easier to read.
The problem is that I have still problems at reading and understanding code that is too much terse... Because I have to assemble in my mind each block, and if there are too many blocks I have problems.
It takes practice to read and to write. The benefit is more expressiveness and more code reuse.
Manlio
Tim Newsham http://www.thenewsh.com/~newsham/