[GHC] #4370: Bring back monad comprehensions

[GHC]

#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 simonpj):

 I agree about `HsStmtContext`.  However I have another idea to suggest
 about `HsDo`, for you to consider.

 At the moment, the last qualifier in a do-block is pulled out as the
 "body" of the do, so that `HsDo` has two arguments:
  * The `[Stmt]` list
  * The final `HsExpr` which is the "body"
 Now, the last qualifier is a bit special, because it must be an
 expression, not a binding form.  But only a bit. My thought is this:
  * Remove the `HsExpr` field of the `HsDo` constructor; instead that field
 simply becomes the last item in the `[Stmt]`.
  * For do-blocks, insist that the last `Stmt` in the list is an
 `ExprStmt`.  (This could be done in the renamer.)
  * For list comprehensions, add a new `Stmt` constructor, `ReturnStmt`,
 which carries the `return` rebindable-syntax term.  (The one you dislike
 attaching to `HsDo`.)
  * The last `Stmt` for a `ListComp` or `MonadComp` must be a `ReturnStmt`.
 Moveover, `ReturnStmt` would only be allowed for `ListComp` and
 `MonadComp`.  We already have constraints of that kind.    For example,
 `TransformStmt` isn't allowed in parallel arrays.

 I think that things used to be like this, and in a fit of mistaken zeal I
 thought it'd be neater to pull out the final `Stmt` specially, but I now
 think that was probably a bad plan.

 How does that sound?  There would be a fair bit of knock-on changes, but
 it'd be pretty rountine refactoring I think. It might be worth making this
 change, validating, and then adding your stuff on top, as a second patch.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4370#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler