# Bringing back Monad Comprehensions (in style)

George Giorgidze giorgidze at gmail.com
Thu Oct 7 15:52:27 EDT 2010

```Hi Sebastian,

> For example:
>
>  [(x, y) | x <- xs | y <- ys]  -- Comprehension.
>
>    versus
>
>  (,) <\$> xs <*> ys             -- Applicative style.
>
>    or
>
>  (| (,) xs ys |)               -- Idiom brackets in She.
>
> Or am I missing some subtle points here?

Perhaps, you meant [(x, y) | x <- xs , y <- ys] which translates to the
following code in the do notation:

do x <- xs
y <- ys
return (x,y)

The comprehension notation also features filters.

[(x, y) | x <- xs , y <- ys, x == y] which for instances of MonadPlus (i.e.,
not for all monads) translates to:

do x <- xs
y <- ys
guard (x == y)
return (x,y)

'order by' and 'group by' to monadic combinators. There, monadic code gets
really unwieldy.

The point of the comprehension notation is that (just like of any other
notation, including do) it makes certain kinds of programs easier to write and
well suited for writing programs that process collections of values. Maybe
this is because the set comprehension notation was hardwired in our brains
during high school math.

Haskell is widely used for EDSL development. Some EDSLs are about processing
collections of values. Monad comprehensions would allow EDSLs to utilise the
expressive list comprehension notation that is currently only allowed for
lists.

Having said that, since the comprehension notation (to some extent) is used in
high school math curricula, even a bit mathematically inclined non-computer
scientist users of list-based EDSLs may feel at home when offered to program
using the comprehension notation.

To summarise, IMO programming list-processing applications is more natural in
the comprehension notation than in do notation and programming with 'group by'
and 'order by' is infeasible in monadic combinators.

Of course one could extend do notation further, but I think it is better for
the reasons outlined above to generalise the list comprehension notation