June 2014 - ghc-tickets

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 18 Jun '14

18 Jun '14

#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 simonpj): I'm not following all of this, but my instinct is this. The semantics of the program should not depend on the details of desugaring. So the various calls to `arr`, `(>>>)` in the desugarer should not dispatch to different instances depending on the size of the tuple. So the type checker should be able to construct functions `arr-at-T`, `(>>>)-at-T` (for the ambient arrow T) ''that are polymorphic in the environment argument''. The desugarer can then instantiate this polymorphic function at whatever types it needs (maybe several of them). I am having trouble getting to grips with this because I know of no document that gives: * The syntax of the arrow sub-language (including comprehensions) * The typing rules for that language * The desugaring for that language Having such a document would be extremely helpful in making sure we were all on staring from the same baseline. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 18 Jun '14

18 Jun '14

#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): > A command can have the form \ p -> cmd, and that's what we have here Ah, so you used `\` to denote the command abstraction (`proc`), not a lambda abstraction? That got me confused. > > 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? > > Yes you do, and that will be harder in the arrow case, because the local environment is an explicit input to the resulting arrow, and the desugarer feels free to trim unused variables from that environment, which will change its type. And that means that at the typechecking stage I have to exactly follow the whole desugaring algorithm, right? Sounds non-trivial. > It would probably be necessary to force the replacements for the arrow combinators to be polymorphic in the environment. This brings me to another question. So let's say the user rebinds `arr` to some function with the type `(Arrow a, Foo b) => a b b`. Then, after desugaring, `arr` is made to operate on data + environment, like in your definition of `bind`: `arr (\ ((e,s),b) -> (e,(b,s)))`. So the type that `arr` operates on may no longer be an instance of `Foo`. What happens? I don't see a way out. > Question: would it be possible as part of this refactoring to have a sort of generalized (weaker) arrow that doesn't have arr? From the discussion on ghc-devs it looks that this is out of scope of this ticket - it probably deserves its own. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 17 Jun '14

17 Jun '14

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ihameed): * cc: idhameed@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 17 Jun '14

17 Jun '14

#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 carter): Question: would it be possible as part of this refactoring to have a sort of generalized (weaker) arrow that doesn't have arr? having arr be baked into the Arrow machinery makes using Arrow for deep embeddings not tenable (such as circuit/frp models that you may wanna compile at runtime). bind has a similar issue, because it allows injecting any haskell function f :: a -> b It may be out of scope for this effort, but figure I should ask -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 17 Jun '14

17 Jun '14

#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 ross): Replying to [comment:30 jstolarek]: > 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? Yes. > 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? It would probably be helpful to add them, but it wouldn't be necessary, just as the libraries don't currently have a definition of `ifThenElse`. The point is that the existing translation is equivalent to translating via these operators, so with `RebindableSyntax` turned on one could translate to those names instead. Then again, always translating via those names would mean less desugaring code, which Simon would approve of. (I've edited comment:17 to add the translation of `rec`, which I forgot before.) > 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). Remember that we're still in the command world here, so the infix operator `bind` is applied to two commands. A command can have the form `\ p -> cmd`, and that's what we have here. The meaning follows from the above implementation of `bind` and the existing translation rules for commands. The `bind`operator will leave the output of the first command on the stack, and the second command will take it off and match it against `p` to extend its local environment. > 4. I assume that this desugaring still requires the stack to store bound parameters (`p` in this example)? The rules for commands other than `do` and `if` would be as before. The lambda would take the argument off the stack, match it against `p`, and add to the local environment an entry for each variable in `p`. > 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? Yes you do, and that will be harder in the arrow case, because the local environment is an explicit input to the resulting arrow, and the desugarer feels free to trim unused variables from that environment, which will change its type. It would probably be necessary to force the replacements for the arrow combinators to be polymorphic in the environment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 17 Jun '14

17 Jun '14

#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

1 0

Re: [GHC] #5902: Cannot tell from an exception handler whether the exception was asynchronous
by GHC 17 Jun '14

17 Jun '14

#5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by liyang): * cc: hackage.haskell.org@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5902#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 16 Jun '14

16 Jun '14

#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 simonpj): I wrote > We are typechecking `pat <- rhs; body` as if it was `(>>=) rhs (\x -> body)`. So we instantiate `(>>=)`, expecting its type to have the shape > {{{ > rhs_ty -> (pat_ty -> body_ty) > }}} > That's what `tcSyntaxOp` does. > > Then we check that `pat` really does have type `pat_ty` and `rhs` really does have type `rhs_ty`. The last sentence is terribly important! We are not just checking that `(>>=)` has a type of the right shape (which is, I gather from your question, what you think is going on), ''but also that it's type can be instantiated to match the particular pattern `pat` and the particular rhs `rhs`''. You aren't doing that with `(>>>)` which is why you have all those uninstantiated type variables. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 16 Jun '14

16 Jun '14

#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 ross): Replying to [comment:27 jstolarek]: > > Why not follow Ross's suggestions in comment 17? > > If I understand correctly Ross' proposal is actually independent of this ticket: we could implement it and still have broken RebindableSyntax. That's why I chose to fix the rebindable syntax first. Perhaps then we can think about alternative desugaring of arrow syntax. 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 translated to several of those combinators. In addition, you have less control of the types of these things, because the translation re-arranges and trims the environment it passes through the arrow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 16 Jun '14

16 Jun '14

#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): > Why not follow Ross's suggestions in comment 17? If I understand correctly Ross' proposal is actually independent of this ticket: we could implement it and still have broken RebindableSyntax. That's why I chose to fix the rebindable syntax first. Perhaps then we can think about alternative desugaring of arrow syntax. > The VOODOO CODING is of course wrong. Well, it is wrong, but I don't yet see why it is wrong. In my code I intended to check that `arr` has type `b -> c -> x b c` (where `x` is an arrow): {{{ arr_op' <- tcSyntaxOp DoOrigin arr_op (mkFunTy (mkFunTy b c) (mkCmdArrTy env b c)) }}} and that `>>>` has type `x a b -> x b c -> x a c`: {{{ compose_op' <- tcSyntaxOp DoOrigin compose_op (mkFunTys [mkCmdArrTy env a b, mkCmdArrTy env b c] (mkCmdArrTy env a c)) }}} I looked at the code you pointed me to and I don't yet see where I went wrong. Do you mean that I should not only check `arr` and `>>>` independently of everything else, but should also check that the type of the whole desugared expression - ie. `arr (\p -> ((xs),())) >>> c'` - is also correct? > Doing the instantiation once, at CmdTop will almost certainly not work. Not sure if I understand what instantiation you mean. You refer to `arr` and `compose`? They are instantiated separately for each data constructor that needs them. `HsCmdTop` was just an example. At the moment I implemented your proposal: every constructor stores operators required for its desugaring and the `CmdSyntaxTable` has been removed. Typechecking is the missing part. I'll be taking a stab at it sometime later this week. There are some examples of typechecking arrows in `TcArrows`, which will hopefully get me on the right track. Once this is done I expect to get tons of minor bugs resulting from my voodoo programming. Hopefully, these will be easy to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0