- ghc-tickets - Haskell.org

Re: [GHC] #1475: Adding imports and exports with Template Haskell
by GHC 18 Jun '14

18 Jun '14

#1475: Adding imports and exports with Template Haskell -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): '''Warning''': allowing splicing of imports would make it much harder to track dependencies between modules, so things like `ghc --make` would become harder. I've only just realised this. So tread carefully here! Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1475#comment:18> 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 simonpj): I didn't know about arrow-rules.pdf! Excellent. Could it have a figure with BNF syntax? (Mirroring the data types in GHC.) Thank you -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:36> 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 ross): Replying to [comment:33 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. Not quite. There are three different grammar items here: {{{ exp ::= \ pat -> exp exp ::= proc pat -> cmd cmd ::= \ pat -> cmd }}} In the last one you're already in the command world, and you want to take a value off the stack and give names to its components for use in the subcommand. > > > 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. If you want to rebind at the level of `arr`, etc, partly (as Simon says) and yes it is. Replying to [comment:34 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''. Yes indeed. And because of the multiple occurrences of `arr` and `>>>` in the translations, this will severely constrain the types of any replacements, to the point that I wonder if the rebinding will solve the original users' issues. > 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. Well there is http://www.haskell.org/ghc/docs/papers/arrow-rules.pdf, but it needs updating to the new stack representation. I'll do that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9190: Iface type variable out of scope: s
by GHC 18 Jun '14

18 Jun '14

#9190: Iface type variable out of scope: s ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I just tried to install criterion with the current GHC HEAD, and `statistics` failed with this message: {{{ /home/jojo/.cabal/lib/x86_64-linux-ghc-7.9.20140609/math- functions-0.1.5.2/Numeric/Sum.hi Declaration for R:MVectorsKBNSum: Iface type variable out of scope: s Cannot continue after interface file error }}} I tried to reproduce this with smaller code than `statistics`, but could not trigger it. The interface dump gives me: {{{ 661d69e55c1491128ac1ed3c03f864e2 axiom TFCo:R:MVectorsKB2Sum:: Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KB2Sum = Numeric.Sum.R:MVectorsKB2Sum s0 a69bb56c3760003bcb7d99cd40c3d843 axiom TFCo:R:MVectorsKBNSum:: Data.Vector.Unboxed.Base.MVector s0 Numeric.Sum.KBNSum = Numeric.Sum.R:MVectorsKBNSum s0 }}} – not sure if there is a `forall` missing or note. Note that these data types are generated using template haskell [http://hdiff.luite.com/cgit /math- functions/tree/Numeric/Sum.hs?id=06b09eb4f110f99fb51a9ec0ec598fba54ac0986#n123 source]. In order to reproduce this, run someting like `cabal install --with-compiler=.../inplace/bin/ghc-stage2 --ghc- option=-XTypeFamilies .` in `statistics-0.11.0.3` with the attached patch applied. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9190> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

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