#4370: Bring back monad comprehensions
---------------------------------+------------------------------------------
Reporter: simonpj | Owner: nsch
Type: feature request | Status: new
Priority: normal | Milestone: 7.2.1
Component: Compiler | Version: 6.12.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by nsch):
I finished the typechecker/desugarer on generators and guards for monad
comprehensions
([http://blog.n-sch.de/2010/11/27/fun-with-monad-comprehensions/ Fun with
monad comprehensions])
and want to give you a quick summary on what
I've done so far. If you have any concerns about those changes, please let
me
know.
=== main/DynFlags.lhs ===
* New `MonadComprehensions` flag.
=== hsSyn/HsExpr.lhs ===
* New `MonadComp` context is added to the `HsStmtContext` data type. It
currently gets a `PostTcTable` argument, very simliar to the `MDoExpr`
context (see the note about typechecking/desugaring below).
* The `ExprStmt` constructor got another `SyntaxExpr` argument, where the
`guard` operation is added by the renamer and later on assures that we
have
an instance of `MonadPlus` in the typechecker.
=== parser/Parser.y.pp ===
* Whenever a list comprehension is found and `MonadComprehensions` is
turned
on, the new `MonadComp` context is passed to the `HsDo` expression
instead
of the old `ListComprehension` context.
=== rename/RnExpr.lhs ===
* New rule in the `rnStmt` function for `ExprStmt`s inside monad
comprehensions, where the `guard` function is looked up and added to
the
`ExprStmt`. This makes sure that we don't get `Not in scope: `guard'`
error
messages inside other `HsDo` expressions, like do blocks or regular
list
comprehensions.
=== typecheck/TcTcExpr.lhs ===
* New rule in `tcDoStmts` for monad comprehensions. A complete new
typechecking function `tcMcStmt` is used to typecheck monad
comprehension
statements. The `BindStmt` rule is very similiar to the typechecking
rule
for `BindStmt` inside do-blocks, the `ExprStmt` is typechecked to type
`bool` (to allow rebindable syntax) and the `guard` function (the new
argument to the `ExprStmt` constructor) is typechecked to `bool ->
res_ty`.
The `LetStmt`s haven't been touched and work the same for every context
anyway. I'm currently working on the `TransformStmt` and `GroupStmt`,
so
they're missing right now. `ParStmt`s will require an
* The `body` (as in `[ body | .. ]`) is typechecked to the type `a` where
the
resulting type of the whole monad comprehension is typechecked to type
`m a`.
See the note on typechecking/desugaring below.
=== deSugar/DsExpr.lhs ===
* New `dsMonadComp` function which is used to desugar monad
comprehensions
into core expressions. I decided that it would be the easiest way to
just
create a new typechecking rule and rewrite the whole desugaring part
for
monad comprehensions since you cannot just translate monad
comprehensions
into do-blocks/list comprehensions and reuse existing desugarers.
However,
I was able to reuse (aka copy & paste) a lot of the existing desugaring
code
of do-blocks (and mdo-blocks).
=== Typechecking/desugaring ===
As mentioned above, the body should be typechecked to type `a`. However,
to be
able to `return` this body to the final `m a` type I need a typechecked
version
of the `return` function in the desugarer. Because I don't wanted to
modify the
body syntax tree in the typechecker (it lead to some strange looking error
messages etc) I added that `PostTcTable` argument to the `MonadComp`
context.
This `PostTcTable` is a list of typechecked functions and their names
which can
be used in the desugarer to build core expressions with those functions.
This
technic is already used with `MDoExpr`s (typecheck/TcMatches.lhs +276 &
deSugar/DsExpr.lhs +818), but I don't know if its the most elegant way to
solve
this issue. Any thoughts on this?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4370#comment:13>
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
