[GHC] #7071: Refactoring arrows

[GHC]

#7071: Refactoring arrows
---------------------------------+------------------------------------------
    Reporter:  simonpj           |       Owner:                  
        Type:  bug               |      Status:  new             
    Priority:  normal            |   Milestone:                  
   Component:  Compiler          |     Version:  7.4.2           
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown    
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:                    |  
---------------------------------+------------------------------------------
Description changed by simonpj:

Old description:

> At the moment arrow commands re-use `HsExpr` for Proc expressions.  But
> with Dan Winograd-Cort I concluded that the best thing by far would be to
> separate the data type of HsExpr from that of arrow commands. I think
> that would lead to a substantial tidy up.
>
> There is also a nasty lurking bug in the type checking of commands; see
> line 290 of TcArrows. Here we call the unifier, but do not do anything
> with the coercion it returns.  This is plainly wrong and will bite
> eventually. But I don't understand this code well enough to fix it.
>
> In short, I am not confident of the arrows implementation at the moment.
>
> Several tickets are blocked on this
>  * #5022 (which is marked as fixed but is a pretty tricky case)
>  * #5267
>  * #5777
>  * #5609
>  * #344
>  * #4359 proposal for `proc case` and multi-branch if

New description:

 At the moment arrow commands re-use `HsExpr` for Proc expressions.  But
 with Dan Winograd-Cort I concluded that the best thing by far would be to
 separate the data type of `HsExpr` from that of arrow commands. I think
 that would lead to a substantial tidy up.

 There is also a nasty lurking bug in the type checking of commands; see
 line 290 of `TcArrows`. Here we call the unifier, but do not do anything
 with the coercion it returns.  This is plainly wrong and will bite
 eventually. But I don't understand this code well enough to fix it.

 In short, I am not confident of the arrows implementation at the moment.

 Several tickets are blocked on this
  * #5022 (which is marked as fixed but is a pretty tricky case)
  * #5267
  * #5777
  * #5609
  * #344
  * #4359 proposal for `proc case` and multi-branch if

--

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