
sorry, wrong function.
should be
partitions [] xs = []
partitions (n:parts) xs =
let (beg,end) = splitAt n xs
in beg : ( case end of
[] -> []
xs -> partitions parts xs)
t = partitions [1,2,3] [1..10]
which is not quite as nice, I admit.
2009/3/25 Thomas Hartman
What about
import Data.List
partAt n xs = let (beg,end) = splitAt n xs in beg : ( case end of [] -> [] xs -> partAt n xs)
t = partAt 3 [1..10]
It's tail recursive (I think!) and should be pretty easy to understand even for a beginner, no?
2009/3/24 Manlio Perillo
: Tim Newsham ha scritto:
These friends are very interested in Haskell, but it seems that the main reason why they don't start to seriously learning it, is that when they start reading some code, they feel the "Perl syndrome".
That is, code written to be "too smart", and that end up being totally illegible by Haskell novice.
I too have this feeling, from time to time.
Since someone is starting to write the Haskell coding style, I really suggest him to take this "problem" into strong consideration.
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 that there is a problem.
The buildPartition contains too many "blocks". And I have read code with even more "blocks" in one line.
It may not be a problem for a "seasoned" Haskell programmer, but when you write some code, you should never forget that your code will be read by programmers that can not be at your same level.
I think that many Haskell programmers forget this detail, and IMHO this is wrong.
Haskell provides the ability to abstract code beyond what many other programming systems allow. This abstraction gives you the ability to express things much more tersely. This makes the code a lot harder to read for people who are not familiar with the abstractions being used.
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.
[...]
Manlio _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe