Bringing back Monad Comprehensions (in style)
haskell at fvisser.nl
Thu Oct 7 07:04:57 EDT 2010
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?
[(x, y) | x <- xs | y <- ys] -- Comprehension.
(,) <$> xs <*> ys -- Applicative style.
(| (,) xs ys |) -- Idiom brackets in She.
Or am I missing some subtle points here?
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 . 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 .
> 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
> Although the quasiquoting approach worked for us, it has a number of
> * 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
> * 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
>  http://www-db.informatik.uni-tuebingen.de/files/weijers/IFL2010complete.pdf
>  http://research.microsoft.com/en-us/um/people/simonpj/papers/list-comp/
More information about the Glasgow-haskell-users