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