October 2014 - ghc-tickets

[GHC] #9689: const_str support needed for hsc2hs in cross-compilation mode
by GHC 16 Oct '14

16 Oct '14

#9689: const_str support needed for hsc2hs in cross-compilation mode -------------------------------------+------------------------------------- Reporter: aosivitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.3 Keywords: zlib ios cross- | Operating System: compilation | Unknown/Multiple Architecture: arm | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Building zlib-0.5.4.1 in cross-compilation mode using ghc-ios fails with the following message: Codec/Compression/Zlib/Stream.hsc:924 directive const_str cannot be handled in cross-compilation mode Is it possible to add support for const_str so that zlib can be built? I am not an experienced GHC developer, but I would be happy to help however I can if it is possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9695: GADT Constraint breaks type inference
by GHC 16 Oct '14

16 Oct '14

#9695: GADT Constraint breaks type inference -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code compiles: {{{ #!haskell {-# LANGUAGE TypeFamilies, MultiParamTypeClasses, GADTs #-} module Foo () where class (Num src, Num tgt) => Bar src tgt where bar :: (tgt, src) type family Type a data CT :: (* -> * -> *) where CT :: --(Type rp ~ Type rq) => rp -> rq -> CT rp rq foo :: (Bar rp rq) => CT rp rq -> CT rp rq foo = let (b', a') = bar in \(CT a b) -> CT (a * a') (b * b') }}} But when I add the [totally irrelevant] constraint to the GADT, `foo` no longer compiles: {{{ Foo.hs:16:22: Could not deduce (Bar t1 t0) arising from a use of ‘bar’ from the context (Bar rp rq) bound by the type signature for foo :: Bar rp rq => CT rp rq -> CT rp rq at testsuite/Foo.hs:15:8-42 The type variables ‘t0’, ‘t1’ are ambiguous Relevant bindings include b' :: t0 (bound at Foo.hs:16:12) a' :: t1 (bound at Foo.hs:16:16) In the expression: bar In a pattern binding: (b', a') = bar In the expression: let (b', a') = bar in \ (CT a b) -> CT (a * a') (b * b') Foo.hs:17:31: Couldn't match expected type ‘rp’ with actual type ‘t1’ ‘t1’ is untouchable inside the constraints (Type rp ~ Type rq) bound by a pattern with constructor CT :: forall rp rq. Type rp ~ Type rq => rp -> rq -> CT rp rq, in a lambda abstraction at Foo.hs:17:12-17 ‘rp’ is a rigid type variable bound by the type signature for foo :: Bar rp rq => CT rp rq -> CT rp rq at testsuite/Foo.hs:15:8 Relevant bindings include a :: rp (bound at Foo.hs:17:15) a' :: t1 (bound at Foo.hs:16:16) foo :: CT rp rq -> CT rp rq (bound at Foo.hs:16:1) In the second argument of ‘(*)’, namely ‘a'’ In the first argument of ‘CT’, namely ‘(a * a')’ Foo.hs:17:40: Couldn't match expected type ‘rq’ with actual type ‘t0’ ‘t0’ is untouchable inside the constraints (Type rp ~ Type rq) bound by a pattern with constructor CT :: forall rp rq. Type rp ~ Type rq => rp -> rq -> CT rp rq, in a lambda abstraction at Foo.hs:17:12-17 ‘rq’ is a rigid type variable bound by the type signature for foo :: Bar rp rq => CT rp rq -> CT rp rq at Foo.hs:15:8 Relevant bindings include b :: rq (bound at Foo.hs:17:17) b' :: t0 (bound at Foo.hs:16:12) foo :: CT rp rq -> CT rp rq (bound at Foo.hs:16:1) In the second argument of ‘(*)’, namely ‘b'’ In the second argument of ‘CT’, namely ‘(b * b')’ }}} The errors can be fixed using `-XScopedTypeVariables` and changing `foo` to: {{{ #!haskell foo :: forall rp rq . (Bar rp rq) => CT rp rq -> CT rp rq foo = let (b' :: rq, a' :: rp) = bar in \(CT a b) -> CT (a * a') (b * b') }}} Why should I need an explicit type on `bar`, when the type can be inferred from its use in `foo` (as it was before the GADT constraint was added)? Is that expected behavior for GADTs? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9695> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5462: Deriving clause for arbitrary classes
by GHC 16 Oct '14

16 Oct '14

#5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by sjoerd_visscher): From the wiki page: "We could try to figure this out in a clever way from the definition of the class being derived, but this is very hard in general." Why is this very hard in general? If I leave out the context in `instance MyClass (MyDatatype a)` then GHC will complain that it is missing `MyClass a`. So can't we use the type checker to give us the required context? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5462#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9670: Make Data.List.tails a good producer for list fusion
by GHC 16 Oct '14

16 Oct '14

#9670: Make Data.List.tails a good producer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.3 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Its structure is trivially an unfold, so it should work well as a producer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9670> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #6018: Injective type families
by GHC 15 Oct '14

15 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): Simon, I'm trying to understand your [comment:76 earlier comment]: > * We are not (at least for now) changing System FC. So the only effect of injectivity is to add extra "Derived" unification constraints, very much like functional dependencies. If we see > {{{ > [W] F t ~ F s > }}} > then we don't decopose it. Instead we add > {{{ > [D] t ~ s > }}} > That guides inference, but does not produce proof terms. So, no, nothing to do with `isDecomposableTyCon`. Much more like the `try_improvement` code in `TcInteract.doTopReactFunEq`. First of all, do we ever get a chance of actually seeing `F t ~ F s`? I think this is not canonical and if such constraint ever appears it would be turned into `F t ~ a, F s ~ a`. I'm not sure which of the canonicalization rules in Fig. 21 in OutsideIn paper would be responsible for that conversion because I don't know the meaning of these stylized D, F and T used in the mentioned figure. My guess would be FFLAT[W/G]R rules. Anyway, once we have `F t ~ a, F s ~ a` we could apply my suggested INJFEQFEQ interaction rule to generate `[D] s ~ t`. If my thinking here is right then shouldn't the implementation go into `TcInteract.interactFunEq` (guessing from its name)? I also wonder whether `[W]` is important in your `[W] F t ~ F s` example? I believe this rule is valid for both given and wanted constraints. I don't understand what you mean by "we don't decopose it". What is this "decomposition" that you mention? I believe that the only moment when injectivity interacts with top-level axioms is when we're deducing LHS from RHS. I suspect this might require a new reaction rule, separate from FINST. Are my ideas here correct? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:90> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 15 Oct '14

15 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): I've read section 7.4 of OutsideIn(X) paper. Code makes more sense now but still I have some questions. Most importantly I'm trying to understand FINST top-level reaction rule (OutsideIn paper, fig. 24 page 65), which according to my understanding is implemented by `doTopReactFunEq`. Since I don't have LaTeX in the wiki I'll be using following notation: \Q - set of top-level axiom schemes \g - little gamma \d - little delta \th - little theta \t - little tau \e - little epsilon _0 - 0 in a subscript \vec{...} - a vector of values, in paper denoted using overline \in - set membership realtion Now the rule: {{{ forall \vec{a}. F \vec{Xi_0} ~ Xi_0 \in \Q -- (1) \vec{b} = ftv(\vec{Xi_0}) -- (2) \vec{c} = \vec{a} - \vec{b} -- (3) \g fresh -- (4) \th = [\vec{b |-> \t_a},\vec{c |-> \g}] -- (5) \th \vec{Xi_0} = \vec{Xi} -- (6) if (l = w) then \vec{\d} = \vec{\g} else \vec{\d} = \e -- (7) ------------------------------------------------------------- topreact[l](\Q, F \vec{Xi}~Xi) = {\d, \th Xi_0 ~ Xi} -- (8) }}} Here's how I understand (or misunderstand that rule): Premise (1) represents a type family equation written by the user (either from a closed or open type family). `\vec{Xi_0}` represents the LHS of `F` ie. patterns in that equation. So for example if the equation is `F [b] Bool c` then `\vec{Xi_0}` is `([b],Bool, c)`. I'm not sure about `[b]` - I think that's not canonical? Are axioms canonicalized? I'm also not sure about the meaning of `\vec{a}` in (1)'s forall. My intuition would be that these are type variables in the LHS (`b` and `c` in above example). But then I don't know how to understand premise (2). If `\vec{b}` represents free variables if `\vec{Xi_0}` then wouldn't this be identical to `\vec{a}`? This does not make sense because in that situation `\vec{c}` in premise (3) would always be empty. Premise (5) is a substitution used in premise (6) to turn the LHS of the original axiom into LHS of a constraint we are trying to solve. But what does `\t_a` represent? Instantiation of variables in the original axiom to some particular values present in `\vec{Xi}`? Premise (7) says that if a constraint is wanted then we introduce new variables. I'm not sure why. Maybe this will become clear once I understand the rest. I'm not sure if I understand the conclusion (8). Reading the rule I see that if we have `F \vec{Xi} ~ Xi` constraint we use it to figure out the `\th` substitution and then use that substitution to create a new constraint that tries to equate the RHS of our current constraint with the RHS of original axiom. But why do we want this? I could use an example with more comments than in the paper (and the example could be more complicated too). Before proceeding with the implementation I'd like to understand how injectivity affects FINST rule. What is not clear to me is whether the new constraint we are producing is wanted or given? My guess is that we produce a given if the original constraint was given and wanted if the original was wanted. I also wonder whether injectivity gives us a new interaction rule: {{{ INJFEQFEQ interact[l] (F \vec{Xi_1} ~ Xi, F \vec{Xi_2} ~ Xi) = (F \vec{Xi_1} ~ Xi, \vec{ Xi_1 ~ Xi_2 }) }}} where `\vec{ Xi_1 ~ Xi_2 }` represents vector of pairwise constraints. A few more questions unrelated to the paper: 1. Are axioms for associated types treated differently than for open type families? 2. What does `BuiltInSynFamTyCon` constructor represent? 3. `Note [Basic Simplifier Plan]` in `TcInteract` mentions "inert reactions" and "spontaneous reactions". What's the difference between the two? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:89> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 15 Oct '14

15 Oct '14

#7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1537, #3613 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D72 | -------------------------------------+------------------------------------- Comment (by simonpj): See also [http://www.haskell.org/pipermail/glasgow-haskell- users/2014-October/025298.html this ghc-users thread]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:51> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
by GHC 15 Oct '14

15 Oct '14

#3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------------+--------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 Differential Revisions: | ---------------------------------------+--------------------------- Comment (by dreixel): I hit this problem too with `criterion` on Windows. `criterion` depends on `hastache`, which depends on `ieee754` without any version bounds. `ieee754-0.7.4` is good, `ieee754-0.7.3` isn't. So I fixed it with the following sequence of commands: {{{ ghc-pkg unregister criterion-1.0.1.0 ghc-pkg unregister hastache-0.6.0 ghc-pkg unregister ieee754-0.7.3 cabal install criterion --constraint="ieee754-0.7.4" }}} Hopefully others can do something similar to this. Also, package authors should update their packages to require `ieee754 >= 0.7.4`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc (was: Rebindable list syntax?)
by GHC 14 Oct '14

14 Oct '14

#7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * owner: => carter Comment: I've been working on designing a set of classes that subsumes this proposal. the work in progress in the class design can be found https://github.com/cartazio/HetList/blob/master/HetList.hs It doesn't yet have the analogues machinery to support the older `fromList` style instances, but thats easy to add. As part of the dev I'm making sure I can write useful instances for the fancy HList libs that are in the while, like `HList` and `Vinyl` after another week or two of polish, I hope to have a candidate patch with the right desugaring (plus some extra work to support current style instances if possible) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7495#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 14 Oct '14

14 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): > I don't know how to do this either. Luckily, we can reject E2 on a first pass. Yes, I believe that's what we should do. If we ever have analysis of unreachable equations for type families then we can use it to deal with `E2` but until then we should simply reject it. As for answers to 1-5 I'll read some more and get back if that doesn't help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:88> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0