Parallel list comprehensions
John Hughes
rjmh at cs.chalmers.se
Sat Feb 4 09:11:10 EST 2006
I noticed ticket #55--add parallel list comprehensions--which according to
the ticket, will probably be adopted. I would argue against.
Firstly: because in its more general forms the notation is confusing. Try
this example:
[(i,j,k) | i<-[1..3], j<-[1..3] | k <- [1..9]]
In general it's hard to predict how the elements from each set of
generators
and filters will match up.
Secondly: because the notation lacks expressive power. When I use zip in a
comprehension, it's often in a definition like this one:
positions x xs = [i | (i,x') <- zip [0..] xs, x==x']
I'm zipping the two lists together *so that I can relate the two* in a
subsequent filter. The parallel comprehension notation cannot express this.
(You can certainly write
wrong_positions x xs = [i | i <- [0..] | x' <- xs, x==x']
but it does the wrong thing).
Thirdly: because even in situations where it can be applied, the gain is
small. Using zip explicitly is almost equally concise, and (thanks to being
explicit) more readable and understandable.
My opinion may be coloured by the fact that I never use the things.
However,
I think it's a mistake to add rarely used features with a small payoff to
the language. It just makes the language larger, harder to learn, and
harder
to read for all but the expert, without much corresponding benefit.
John
More information about the Haskell-prime
mailing list