Lambda the Ultimate

It seems strange to me to encourage people to use the 'Order by' keyword for other things than sorting, just becourse the type system allows it.

They give the type
(a -> b) -> [a] -> [[a]]
I've always imagined the type as
(a -> k) -> [a] -> Map k [a]
because you always need the value you grouped by later.

With the type in the paper you have to reconstruct the grouping value, which might not always be as simple as the dept.

Actually, the same goes for sorting, so maybe the following functions might work best:
by :: (a -> k) -> [a] -> [(k, a)]
sortByFirst :: [(k, a)] -> [(k, a)]
groupByFirst :: [(k, a)] -> Map k [a]

But it is harder to merge this with list comprehension syntax.

What does iterate do in Haskell, it is used in at least one example and probably in the LIMIT equivalent (order using take).

I really, really hope that this never gets into Haskell. It looks ugly. It's too "magical" for my tastes (and thus, I see it being confusing for many in all but trivial cases). Along those lines, I see it easily abused (much more significant than merely abusable.) I feel it would lead people away from many more natural solutions (though I will readily admit that it may often be a natural solution itself.) It's too inflexible, I'd rather see a new library of combinators or some such (which I also feel would be more Haskelly/natural.) I like ending my comments with parenthetical remarks (as you can see.)

Their examples in chapter 2 can be done much easier if you use records.

map (\(name,salary) -> name)
(sortWith (\(name,salary) -> salary)
[ (name,salary)
| (name, salary, dept) <- employees
, salary < 50 ])

becomes

map name (sortWith salary [ e | e <- employees, salary(e) < 50 ])

and

let
depts =
nub [ dept
| (name,dept,salary) <- employees ]
in
[ (dept,
sum [ salary
| (name,dept’,salary) <- employees
, dept == dept’])
| dept <- depts ]

becomes

[(dept (head group), sum (map salary group)) | group <- groupWith dept employees]

To me, the major benefit of comprehensions is that they enable us to express frequent programming patterns by referring to simple things with variables, rather than combining higher-order functions.

Philip and Simon's new extensions further enable us to express frequent programming patterns pointfully. Still, this scheme feels a bit arbitrary. I wonder if there is a nicer generalization, perhaps less directly mapped to SQL.

Sjoerd gets to the core of the issue, that records make for cleaner comprehensions than pattern-matched algebraic data types. With idiomatic Haskell ADTs, you frequently must invent redundent local names for tupled elements in an ADT.

...come back one day. This extension seems incompatible with monad comprehensions and would dash my hopes that they could ever reappear.

...to beat this dead thread, but anyway:

We propose an extension to list comprehensions that makes it easy to express the kind of queries one would write in SQL

I do not argue that in practice one often wants to query algebraic data structures. However, I see a slight mismatch between the context of SQL and comprehensions. SQL is used to formulate a proposition about desired result, which is then analysed by optimizer to obtain a query plan (a proof of the proposition, if you like). In order to do something similar in Haskell, one has either (A) to be able to inspect arbitrary code by optimizer, or (B) to give up embedding Haskell code into query DSL (hi, Philippa!), or (C) to strike some middle ground and only allow optimizer/plan builder built into the compiler (the way usually proposed for comprehensions and extensions to them).
Plan C sounds limiting and totalitarian, plan B will require to build DSL from scratch without reusing wealth of language features from Haskell, plan A - well, does Template Haskell allows something like this?