#4370: Bring back monad comprehensions
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.12.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
George Giorgidze writes: My colleagues and I are working on Haskell [http
://www-db.informatik.uni-tuebingen.de/files/weijers/IFL2010complete.pdf
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
[http://research.microsoft.com/en-us/um/people/simonpj/papers/list-comp/
'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
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 enerated 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?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4370>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
