Bringing back Monad Comprehensions (in style)

[Sebastiaan Visser]

What exactly are the benefits of Monad comprehensions over, for example, the do-notation or idioms?

I'm not fully aware of what Monad comprehensions would offer in general, but aren't most comprehensions directly translatable to applicative style?

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?

Cheers,
Sebastiaan

On Oct 5, 2010, at 4:41 PM, George Giorgidze wrote:
> Bringing back Monad Comprehensions (in style).
> 
> Dear GHC users,
> 
> My colleagues and I are working on Haskell embedded DSL for data-intensive and
> data-parallel applications [1]. The idea is to provide the Haskell list
> prelude combinators to manipulate database-resident data. The combinators are
> not executed in Haskell runtime, instead they are compiled down to SQL,
> executed on relational database systems and the results are marshalled back to
> Haskell for further in-heap processing or generation of new database-able
> embedded programs.
> 
> Although programming with the standard list processing combinators is
> feasible, the embedded programs are much more concisely formulated using the
> list comprehension notation, especially, when extended with 'order by' and
> 'group by' constructs [2].
> 
> Unfortunately, in Haskell, the list comprehension notation is only available
> for processing lists.
> 
> In order to support the list comprehension notation, we have built a
> quasiquter that desugars the list comprehension notation, but, instead of
> generating code using the Haskell list prelude combinators the quasiquter
> generates code that uses list processing combinators from our embedded
> language.
> 
> Although the quasiquoting approach worked for us, it has a number of
> drawbacks:
> 
>  * Introduces extra syntactic noise
> 
>  * Error messages are hard to understand as they refer to generated code
> 
>  * Needs to be re-implemented for every list-based embedded language
> 
> One way to address the aforementioned drawbacks is to define our queries as a
> monad (similar to list monad) and use the monad comprehension notation. The do
> notation can be used but it is less suited for query languages.
> 
> Unfortunately monad comprehensions were removed from Haskell, prior to Haskell
> 98. However, I think that the notation is extremely useful not only for lists,
> but for other list like data structures, list-based query languages (see
> above), maybe even for wider range of EDSLs and monads. I think the feature
> deserves to be supported at least as a GHC language extension.
> 
> Thus, I would like to propose to design and implement the monad comprehension
> notation as a GHC language extension. I am willing to invest some time and
> contribute to this effort.
> 
> One can also look at how recently introduced 'order by' and 'group by'
> constructs generalise to monad comprehensions. If that works, one could
> implement even more "stylish" monad comprehension notation.
> 
> Feedback from GHC users and developers would be very much appreciated.
> 
>  * Do you think that this is a good idea?
> 
>  * Would you use monad comprehensions (if available) for your
>    library/EDSL/application?
> 
>  * Do you think that it would be hard to integrate this extension into
>    current GHC codebase?
> 
>  * Have you already thought about how to generalise 'order by' and 'group
>    by' to monad comprehensions?
> 
>  * Have you already thought about how to address the original objections to
>    the monad comprehension notation?
> 
> Cheers, George
> 
> [1] http://www-db.informatik.uni-tuebingen.de/files/weijers/IFL2010complete.pdf
> 
> [2] http://research.microsoft.com/en-us/um/people/simonpj/papers/list-comp/
>