#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`.

I don't see how the former can work, as each language construct is

you have less control of the types of these things, because the

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]: 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`. 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