June 2014 - ghc-tickets

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 SimonHengel): Just because I've been pushing for this in the past, I solved my use case in a different way. For me closing this as won't fix would be ok. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1475#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9217: GHCi accepts any operator as a value constructor when enclosed in parens
by GHC 18 Jun '14

18 Jun '14

#9217: GHCi accepts any operator as a value constructor when enclosed in parens ------------------------------------+------------------------------------- Reporter: wz1000 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Eg:- 'data P = (+) Char Char' is accepted by GHCi However 'data P = (-) Char Char' is accepted by GHCi 7.8.2, but is reported to be rejected by GHC 7.6.3 GHCi 7.4 is reported to reject these inputs. GHC 7.8.2 also rejects these inputs. Operators defined this way are inaccessible and do not shadow existing operators. Legal operators(those prefixed by a colon) act normally -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9217> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9138: Allow users to edit their own tickets
by GHC 18 Jun '14

18 Jun '14

#9138: Allow users to edit their own tickets ------------------------------------+------------------------------------- Reporter: nomeata | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Non-power-users can edit their own comments, but not their tickets. That is annoying when one makes mistakes in the syntax. There is a history of changes, so it really wouldn't be a problem to allow that. The required permissions according to [TracPermissions] seems to be `TICKET_EDIT_DESCRIPTION`. `TICKET_EDIT_CC` would also be useful (#8881), as I can put people on CC when I create a ticket, but I cannot change that later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7673: Windows: run "git config --global core.autocrlf false" before cloning the repo
by GHC 18 Jun '14

18 Jun '14

#7673: Windows: run "git config --global core.autocrlf false" before cloning the repo -------------------------------+------------------------------------ Reporter: morabbin | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------ Changes (by thomie): * cc: hvr (removed) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7673#comment:5> 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:37 jstolarek]: > Now I see this was even mentioned in "A New Notation for Arrows" paper. Again there's something I don't understand here. So far I though that stack is an implicit mechanism that is used to pass around values bound using `<-`. But here it seems that the user is allowed to explicitly access the stack. Isn't that a bit risky? The local environment is used to pass around values bound inside the `proc` expression. The stack is used to pass around anonymous values. They can be pushed using application, popped and named in the environment by command lambda, and also manipulated by control operators. The type constraints on operators keep them well behaved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:38> 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): Replying to [comment:34 simonpj]: > 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''. My concern was what if the `arr` defined by the user cannot be made polymorphic in the environment argument? According to my understanding of this bug report the problem is that during desugaring all calls to user-defined `arr` are instantiated to be the same and thus typechecking fails, because different types are required at different call sites. Why the same thing doesn't happen without rebinding? Replying to [comment:35 ross]: > 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. Now I see this was even mentioned in "A New Notation for Arrows" paper. Again there's something I don't understand here. So far I though that stack is an implicit mechanism that is used to pass around values bound using `<-`. But here it seems that the user is allowed to explicitly access the stack. Isn't that a bit risky? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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