[GHC] #7828: RebindableSyntax and Arrow

[GHC]

#7828: RebindableSyntax and Arrow
----------------------------------------------+----------------------------
        Reporter:  AlessandroVermeulen        |            Owner:
            Type:  bug                        |  jstolarek
        Priority:  normal                     |           Status:  new
       Component:  Compiler (Type checker)    |        Milestone:  7.10.1
      Resolution:                             |          Version:  7.6.2
Operating System:  Unknown/Multiple           |         Keywords:
 Type of failure:  GHC rejects valid program  |     Architecture:
       Test Case:                             |  Unknown/Multiple
        Blocking:                             |       Difficulty:  Unknown
                                              |       Blocked By:
                                              |  Related Tickets:  #1537,
                                              |  #3613
----------------------------------------------+----------------------------

Comment (by jstolarek):

 Replying to [comment:28 ross]:
 > It's not so much an alternative desugaring as a different view of the
 existing desugaring in which `do` and `if` can be rebound in an analogous
 manner to the way they're rebound in the expression world.  Or it's a re-
 interpretation of this ticket: instead of using private versions of `arr`,
 `>>>` and `first`, the idea is to use private versions of the control
 operators `bind`, `bind_` and `ifThenElseA`, the arrow counterparts of
 `>>=`, `>>` and `ifThenElse`.

 A few more questions to make sure that I understand:

 1. If your solution was implemented then `bind`, `bind_` and `ifThenElseA`
 would be rebindable and `arr` & friends would not?

 2. `bind`, `bind_` and `ifThenElseA` currently don't exist in the
 libraries. Implementing yor proposal would require adding their
 definitions to Control.Arrow. Desugared arrow notation would call these
 default definitions, unless `RebindableSyntax` is enabled, in which case
 we use the definitions of `bind` etc. that are currently in scope.
 Correct?

 3. In comment:17 you wrote:

 {{{
 do { p <- cmd; stmts } = cmd `bind` \ p -> do { stmts }
 }}}
   Is `\ p -> do { stmts }` a shorthand for "put `p` on the stack and
 desugar `do { stmts }`"? If not, then what does it mean (code as written
 does not typecheck because `bind` needs an arrow, not a lambda).

 4. I assume that this desugaring still requires the stack to store bound
 parameters (`p` in this example)?

 Replying to [comment:28 ross]:
 > I don't see how the former can work, as each language construct is
 translated to several of those combinators.

 This seems technically simple to me: just store in a constructor as many
 copies of the required combinators as necessary for desugaring. Although
 simple it leads to a design I'm not happy with. For example `RecStmt`
 requires 11 (sic!) combinators to desugar: 5x `>>>`, 4x `arr`, `first` and
 `loop`.

 > you have less control of the types of these things, because the
 translation re-arranges and trims the environment it passes through the
 arrow.

 Yes, if I need to write down the exact types for typechecking this becomes
 a problem. Which brings me to another question related to Simon's answer:

 Replying to [comment:29 simonpj]:
 > The last sentence is terribly important!

 That's what I suspected. So in the typechecker we type check `pat <- rhs;
 stmt` as if it was `rhs >>= \pat -> stmt` and later in the desugarer we
 actually convert it to such form, right? So if I want to typecheck the
 arrow desugaring I need to typecheck *exactly* the form to which it will
 later be desugared, including all the explicit stacks, etc?

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