January 2015 - ghc-tickets

[GHC] #9981: MALE SUPPLEMENT
by GHC 13 Jan '15

13 Jan '15

#9981: MALE SUPPLEMENT -------------------------------------+------------------------------------- Reporter: | Owner: ChesterDicus | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: MAXX TEST | Type of failure: None/Unknown 300 | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- You ever have been before to having the body in the life the you deserve and desire you’re going to wake up just a few days from now it's your muscles fall in vascular you're going to have to conserve energy party at [http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ MAXX TEST 300] the gym because you can feel that this is already working picture yourself just a few weeks from now strong confident Norris respected forth first time a match in the feeling you're going to have when even the hottest girls heads turn your way every single day it's time to make this happen click . http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9981> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9980: MUSCLES BUILDING
by GHC 13 Jan '15

13 Jan '15

#9980: MUSCLES BUILDING -------------------------------------+------------------------------------- Reporter: | Owner: ChesterDicus | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: MAXX TEST | Type of failure: None/Unknown 300 | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- You'll receive anonymous part one hundred percent no questions asked refund but wait there's more you can start right away because I'm going to download [http://www.x4facts.com/before-buying-maxx-test-300-read-it- first/ MAXX TEST 300] everything from my website to your computer don't worry this issuer easy if you can open your email you can do this but I'll personally walk you through this step-by-step on the next page you're about to get instant access tithe complete package I know you were closer . http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 12 Jan '15

12 Jan '15

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Segmentation fault, segfault, long Type of failure: Runtime crash | input Blocked By: 4258 | Architecture: x86_64 Related Tickets: | (amd64) | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * priority: highest => high Comment: Not release-blocking -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7398: RULES don't apply to a newtype constructor
by GHC 12 Jan '15

12 Jan '15

#7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #6082 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by liyang): * cc: ghc.haskell.org@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7398#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 10 Jan '15

10 Jan '15

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | TypeFamilies, Injective Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4259 | Test Case: | Blocking: | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:103 jberryman]: > I've only had use for better type inference with (conceptually) closed, recursive type families Calling type families from an injective type family will not be allowed (including recursion). The reason is that I don't see a way of verifying injectivity when type families are involved. > What I think I want is something like proposal C from the wiki At the moment I am implementing proposals A and B. C is something to think about in the future, as it is not trivial. > And as a naive user I want injectivity to be inferred for closed type families, and don't find the arguments against it in the wiki convincing. Yes, I suppose that focus of the wiki discussion is a bit off. I think we could infer injectivity of type A for closed type families. But I don't think we should try to infer injectivity of type B because the algorithm is exponential - see [comment:64 comment 64]. That's the major reason for doing this. (Numbers in that comment were computed for type C injectivity, but type B is also exponential.) {{{#!hs -- | The algebraic normal form 'Exponent' @abc@ distributed over the single -- base variable @x@. type family abc :=>-> x -- | x¹ = x type instance () :=>-> x = x -- | x⁽ᵃᵇ⁾ = (xᵇ)ᵃ type instance (a,bs) :=>-> x = a -> bs :=>-> x }}} I don't think `:=>->` type family is injective: both `() :=>-> (Int -> Int)` and `(Int,()) :=>-> Int` reduce to `Int -> Int`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8440: Get rid of the remaining static flags
by GHC 09 Jan '15

09 Jan '15

#8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8440#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 09 Jan '15

09 Jan '15

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | TypeFamilies, Injective Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4259 | Test Case: | Blocking: | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by jberryman): I'm very late to the discussion, so this is probably not helpful at all, but I wanted to mention my interest. I've only had use for better type inference with (conceptually) closed, recursive type families. What I think I want is something like proposal C from the wiki, or the head- injectivity proposal where "possibly-partial information about the result might allow us to deduce possibly-partial information about the arguments." And as a naive user I want injectivity to be inferred for closed type families, and don't find the arguments against it in the wiki convincing. Intuitively there doesn't seem to be much difference between the level of logic required to infer things about types with closed type synonym families, vs the sort of inference the typechecker does elsewhere (again, as a naive user who doesn't care about the trickiness of implementing such a scheme). My impression is that this is what many people assumed would be the point of closed type families; for what I've had in mind closed type families make only a cosmetic improvement. Anyway most of my interest came from my work on https://github.com/jberryman/shapely-data which embarrassingly seems to dependent quite a lot on #1241, so it (and below) needs GHC 7.6. You can ignore the example that follows or consider it if it's helpful: {{{#!hs {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} -- for nested Type family: Reversed (Tail t) :> Head t {-# LANGUAGE FunctionalDependencies #-} -- | A class for the exponent laws with the 'Normal' form @abc@ in the exponent -- place. See the instance documentation for concrete types and examples. class Exponent abc where fanin :: (abc :=>-> x) -> (abc -> x) unfanin :: (abc -> x) -> (abc :=>-> x) -- | The algebraic normal form 'Exponent' @abc@ distributed over the single -- base variable @x@. type family abc :=>-> x -- | x¹ = x type instance () :=>-> x = x -- | x⁽ᵃᵇ⁾ = (xᵇ)ᵃ type instance (a,bs) :=>-> x = a -> bs :=>-> x instance Exponent () where fanin = const unfanin f = f () instance (Exponent bs)=> Exponent (a,bs) where fanin f = uncurry (fanin . f) unfanin f = unfanin . curry f class Homogeneous a as | as -> a where -- An n-ary @codiag@. genericRepeat :: a -> as instance Homogeneous a () where genericRepeat _ = () instance (Homogeneous a as)=> Homogeneous a (a,as) where genericRepeat a = (a,genericRepeat a) }}} So the following two type-check fine: {{{#!hs a = (3 ==) $ (\(x,(y,(z,())))-> x+y+z) $ genericRepeat 1 b = (3 ==) $ fanin (\x y z-> x+y+z) (genericRepeat 1 :: (Int,(Int,(Int,())))) }}} But this doesn't: {{{#!hs c = (3 ==) $ fanin (\x y z-> x+y+z) $ genericRepeat 1 }}} ...failing with {{{ Couldn't match expected type `a1 -> a1 -> a1 -> a1' with actual type `abc0 :=>-> a0' The type variables `a0', `abc0', `a1' are ambiguous Possible fix: add a type signature that fixes these type variable(s) The lambda expression `\ x y z -> x + y + z' has three arguments, but its type `abc0 :=>-> a0' has none In the first argument of `fanin', namely `(\ x y z -> x + y + z)' In the expression: fanin (\ x y z -> x + y + z) }}} That library is probably going in the garbage bin at this point, but in general this is the sort of thing I think I'd like to be able to do with type families eventually. And I haven't gotten to dig into y'all's singletons work yet, so it might be that that's the sort of thing I'm looking for and my use of type families and classes in shapely-data is ill-considered. Thanks for your work on this! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:103> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9973: Erroneous Redundant constraint warning
by GHC 09 Jan '15

09 Jan '15

#9973: Erroneous Redundant constraint warning -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using version 4425ab99d6410839fa7567950b0a4696b0a3d70f with D538 applied, If the attached source file is loaded as is into ghci it generates the following warning for line 5, but otherwise loads fine {{{ /home/alanz/mysrc/github/alanz/HaRe/Bug2.hs:5:18: Warning: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t => [GHC.LHsBind GHC.Name] -> t -> GHC.Name -> GHC.Name -> IO [GHC.LHsBind GHC.Name] }}} If the constraint is commented out, it results in an error {{{ /home/alanz/mysrc/github/alanz/HaRe/Bug2.hs:26:16: No instance for (SYB.Data t) arising from a use of ‘definingSigsNames’ Possible fix: add (SYB.Data t) to the context of the type signature for: duplicateDecl :: [GHC.LHsBind GHC.Name] -> t -> GHC.Name -> GHC.Name -> IO [GHC.LHsBind GHC.Name] In the expression: definingSigsNames [n] sigs In an equation for ‘typeSig’: typeSig = definingSigsNames [n] sigs In an equation for ‘duplicateDecl’: duplicateDecl decls sigs n newFunName = do { let sspan = ...; newSpan <- case typeSig of { [] -> return sspan _ -> ... }; let rowOffset = ...; .... } where typeSig = definingSigsNames [n] sigs Failed, modules loaded: none. }}} This behaviour goes away if the following lines are commented out {{{#!hs let rowOffset = case typeSig of [] -> 2 _ -> 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9973> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9900: Support pattern synonyms in GHCi
by GHC 09 Jan '15

09 Jan '15

#9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Keywords: PatternSynonyms | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 8749, 7253 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Pattern synonyms are not parsed in GHCi: {{{ λ» :set -XPatternSynonyms λ» pattern P x = x <interactive>:5:1: parse error on input ‘pattern’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9900> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9875: ld -l:filename.dylib does not appear to be portable
by GHC 09 Jan '15

09 Jan '15

#9875: ld -l:filename.dylib does not appear to be portable ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: T2276_ghci Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+------------------------------------- In GHCi, we seem to use `-l:` to ask the linker to link a specific filename, instead of munging the filename. Unfortunately, this does not appear to be universally supported by all versions of `ld`. Here is the manpage `ld` that comes with Mac OS X 10.10.1: {{{ Options that control libraries -lx This option tells the linker to search for libx.dylib or libx.a in the library search path. If string x is of the form y.o, then that file is searched for in the same places, but without prepending `lib' or appending `.a' or `.dylib' to the filename. }}} It causes T2276_ghci to fail: {{{ --- /dev/null 2014-12-09 20:57:29.000000000 -0500 +++ ./T2276_ghci.run.stderr 2014-12-09 20:57:30.000000000 -0500 @@ -0,0 +1,3 @@ +ld: library not found for -l:ghc75404_1.dylib +clang: error: linker command failed with exit code 1 (use -v to see invocation) +phase `Linker' failed (exitcode = 1) *** unexpected failure for T2276_ghci(ghci }}} Regression seems to have been introduced by: {{{ commit 383733b9191a36e2d3f757700842dbc3855911d9 Author: Peter Trommler <ptrommler(a)acm.org> Date: Sun Nov 30 12:00:39 2014 -0600 Fix obscure problem with using the system linker (#8935) }}} Probably we can fix it by not using colon and making sure the libraries we generate have the right file format. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9875> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11