Good idea. I've made a new Trac ticket and responded there. I suggest that others do the same, so the conversation is captured in the ticket. http://hackage.haskell.org/trac/ghc/ticket/4370 You can add yourself to the cc list of the ticket to stay in the loop. Of course, do use the mailing list too for clarifying discussion, and then dump the conclusion in the ticket. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of George Giorgidze | Sent: 05 October 2010 15:42 | To: glasgow-haskell-users@haskell.org | Subject: Bringing back Monad Comprehensions (in style) | | 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/ | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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/