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/ > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users