March 2017 - ghc-tickets

[GHC] #13177: Give Data.Functor.* its lifted unit and void
by GHC 09 Mar '17

09 Mar '17

#13177: Give Data.Functor.* its lifted unit and void -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `GHC.Generics` has {{{#!hs data U1 a = U1 data V1 a }}} They are simple but why are they not present in the `Data.Functor` hierarchy along with functions like (from [https://hackage.haskell.org/package/one-liner-0.7/docs/src/Generics- OneLiner-Internal.html one-liner]) {{{#!hs absurd :: V1 a -> b absurd = \case }}} Packages like [https://hackage.haskell.org/package/linear linear] provide basically the same lifted functors {{{#!hs data V0 a = V0 newtype V1 a = V1 a }}} if they or those from `GHC.Generics` should be preferred it could be added to the documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals
by GHC 08 Mar '17

08 Mar '17

#13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I just noticed that compiling `xmlhtml-0.2.3.5` from Hackage takes an extraordinarily long time on GHC HEAD. The slowdown can be attributed to the `Text.XmlHtml.HTML.Meta` module. I've extracted it and tweaked it so that it requires no dependencies to build (I now use `ByteString` instead of `Text`, but the slowdowns for both types were about the same.) On GHC 8.0.2, it takes about 3 seconds to compile the attached module: {{{ $ /usr/bin/time /opt/ghc/8.0.2/bin/ghc -fforce-recomp TextXmlHtmlHTMLMeta.hs [1 of 1] Compiling Text.XmlHtml.HTML.Meta ( TextXmlHtmlHTMLMeta.hs, TextXmlHtmlHTMLMeta.o ) 3.44user 0.07system 0:03.51elapsed 99%CPU (0avgtext+0avgdata 208480maxresident)k 0inputs+21688outputs (0major+43934minor)pagefaults 0swaps }}} But on GHC HEAD, it takes about 10 seconds: {{{ $ /usr/bin/time ~/Software/ghc2/inplace/bin/ghc-stage2 -fforce-recomp TextXmlHtmlHTMLMeta.hs [1 of 1] Compiling Text.XmlHtml.HTML.Meta ( TextXmlHtmlHTMLMeta.hs, TextXmlHtmlHTMLMeta.o ) 9.93user 0.11system 0:10.03elapsed 100%CPU (0avgtext+0avgdata 233656maxresident)k 0inputs+21464outputs (0major+54853minor)pagefaults 0swaps }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13395> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13341: Lift constraint products
by GHC 08 Mar '17

08 Mar '17

#13341: Lift constraint products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to get a discussion going, could we lift constraint products automatically. Although not partially applicable, we can consider `(,)` as having kind {{{#!hs (,) :: Constraint -> Constraint -> Constraint }}} I propose also giving it kinds {{{#!hs (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' -> Constraint) -- etc. }}} == Translation {{{#!hs (Eq, Num, Show) (Monad, Foldable) (Category, Profunctor) }}} gets turned into something like {{{#!hs class (c a, d a) => (c :&: d) a instance (c a, d a) => (c :&: d) a infixl 7 :&: Eq:&:Num:&:Show Monad:&:Foldable Category:&:Profunctor }}} == Uses Very often I need to be able to combine constraints. A small modification of [https://hackage.haskell.org/package/free- functors-0.7.2/docs/Data-Constraint-Class1.html SuperClasses] {{{#!hs type c :~ d = forall xx. c x :- d xx class HasSuperClasses (c :: k -> Constraint) where type SuperClasses c :: k -> Constraint type SuperClasses c = c superClasses :: c :~ SuperClasses c containsSelf :: SuperClasses c :~ c instance HasSuperClasses Functor where superClasses :: Functor :~ Functor superClasses = Sub Dict containsSelf :: Functor :~ Functor containsSelf = Sub Dict instance HasSuperClasses Foldable where superClasses :: Foldable :~ Foldable superClasses = Sub Dict containsSelf :: Foldable :~ Foldable containsSelf = Sub Dict }}} I want to be able to write {{{#!hs instance HasSuperClasses Traversable where type Traversable = (Traversable, Functor, Foldable) superClasses :: Traversable :~ (Traversable, Functor, Foldable) superClasses = Sub Dict containsSelf :: (Traversable, Functor, Foldable) :~ Traversable containsSelf = Sub Dict }}} If this doesn't pose any difficulties I'll open a GHC proposal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13341> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 08 Mar '17

08 Mar '17

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): Just a quick update, I've gone through about 4 rewrite of the core parts of this patch. The biggest issue is with how GHC accesses const data. This forces me to essentially write a unix like dynamic loader in the binaries because of how closures and info tables are accessed. Or use bounded imports and forgo the ability to use ASLR with GHC applications, which is a heavy price. Also `dlltool` is very slow, too slow to be usable at the scale required. GHC has managed to bloat up to a size where it has to be split into 3 DLLs (nearing a 4th). The automatic splitting works fine, but the resulting import libraries require `dlltool` to process 3x ~65k symbols. Which it takes half an hour to do and generates huge file sizes. This is because the way import libraries are implemented in binutils is a hack. Microsoft's own `lib.exe` tool does this in seconds and creates a much much smaller file. This means I also have to write a tool to generate import libraries in their short format for use by GHC. I still expect to finish by `8.4.1`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:63> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Trac email verification for user: Forec
by GHC 08 Mar '17

08 Mar '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=IIngV55n> Username: Forec Verification Token: IIngV55n -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8255: GC Less Operation
by GHC 08 Mar '17

08 Mar '17

#8255: GC Less Operation ------------------------------+-------------------------------------------- Reporter: sirinath | Owner: Type: feature | Status: new request | Milestone: Priority: highest | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Hi, Is it possible to eliminated GC through Automatic Reference Counting (ARC) like in Objective C / Clang. S -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8255> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints
by GHC 08 Mar '17

08 Mar '17

#2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): Your `min` discussion was helpful to me, but I think it's mostly unrelated, in retrospect; the `Ord a` dictionary -- again ignoring overlapping/incoherent instances -- could only ever "overlap" with a parametric instance of `Ord`, since `a` is skolem. #9701, on the other hand, seems to demonstrate exactly what you were getting at (#12791 too?). Replying to [comment:14 goldfire]: > I initially put this ticket into my internal notes as "Difficulty: Rocket Science", but I've changed my mind. I think this is actually straightforward to implement. > > GHC already has implication constraints, except that they're effectively all Wanteds. So, all we would need are to be able to make Given implication constraints. But, these should be rather straightforward, because we can view top-level instances as Given implication constraints. We can just adapt the current look-in-Givens algorithm to do some matching, just like the instance-selection algorithm does. When we find an implication-constraint Given that matches a Wanted, we use it to solve the Wanted and then emit new Wanteds for the antecedents of the Given implication. > > I was initially concerned about overlap here -- what if an implication Given's RHS overlaps with a global instance? -- but this was a red herring. Givens have always potentially overlapped with global instances, and very few people are bothered. For example: > > {{{ > min :: Ord a => a -> a -> a > }}} > > If we call `min` at type `Int`, the `Ord` constraint is potentially ambiguous: do we mean the dictionary supplied or the global `Ord Int` dictionary? Of course, we mean the local one, and we don't require `-XIncoherentInstances` to do so. So, worrying about overlap in the context of implication Givens is a red herring. We have a clear rule: local constraints always shadow global ones. That's nice, simple, and unsurprising. > > This also doesn't change the "GHC never backtracks" principle. If a local implication-constraint's RHS matches, it is used, just like if GHC finds a global implication constraint (read, global constrained instance). > > To implement this, GHC would also need to be able to produce the witness for an implication constraint, but this is just like inferring the lambdas for a higher-rank type. I don't see any challenge here. > > Of course, a niggling feeling tells me that this ''has'' to be harder than I'm seeing it. But, really, all I see standing in the way is a bit of plumbing. > > Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2256#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints
by GHC 08 Mar '17

08 Mar '17

#2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): Does the following claim hold water and/or illuminate anything? The implication constraint on `implic` can either be simplified (eg `C a` immediately refines `a` and/or has `D a` as a superclass) or it is only satisfiable by a parametric instance of `D`. Suppose that overlapping and incoherent instances are not allowed. Then any non-parametric instance of `D` (eg your `D Int`) would immediately render that implication constraint unsatisfiable. So the concern is just yet another due solely to overlapping/incoherent instances? Replying to [comment:16 goldfire]: > * Inference: We don't. Just like we don't infer higher-rank types (which, of course, are the same as implication constraints). If a user wants this feature, they have to ask for it. > > * Completeness: This is thornier. Here is how I see a problem arising: > > {{{ > class C a > class D a > instance D Int > > needsD :: D a => a -> () > implic :: (forall a. C a => D a) -> () > implic = needsD (5 :: Int) > }}} > > When typechecking `implic`, the local universal dictionary for `D a` will be used to provide a dictionary to `needsD`. This will then generate an unsatisfiable wanted `C Int`. But, of course, we could have just used the global instance `D Int` instead. > > An issue such as this one can't arise today (even with local dictionaries shadowing global ones) because local dictionaries never give rise to new wanteds. If you have a local dictionary, it's good to use. > > Given/Given interactions would be the same. If one implication-Given can be used in an interaction, it would be, giving rise to its antecedent Wanted constraints. > > This does get me a little worried about nondeterminism. But, I conjecture that if this interaction can give rise to nondeterminism, then it would be possible to exhibit the nondeterminism today, using overlapping instances. > > So, it all comes down to specifying completeness against what spec, and I'm saying that we could be complete against a spec where every local constraint shadows every overlapped global one. That is, when `(forall a. C a => D a)` is in scope, `instance D Int` is not. Will this be easy enough to use to make it practicable? There will be some surprises around it, but I think it's all quite easy to digest with a little guidance. (Certainly easier to understand than closed type families!) > > * Impredicativity: This, to me, is just like the story in kind `*`. `c` should be forbidden from unifying with an implication constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2256#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c
by GHC 08 Mar '17

08 Mar '17

#13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c ------------------------------+------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+------------------------------- When you press and hold Ctrl-c, after a few seconds, sometimes > 60 sec, GHCi crash and we can read a message on the screen (of the console) who says: {{{ ghc.exe : failed to create OS thread }}} On the task manager we can read: {{{ ghc memory : 36920K }}} initially, then the memory grows about {{{ ghc memory : 43480K }}} and stay until the crash. I repeated it several times. With Linux if you repeat this, GHCi do not crash. Idem with only the Windows console. Hope this help! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] Trac email verification for user: sheyll
by GHC 07 Mar '17

07 Mar '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=JSlhZPyV> Username: sheyll Verification Token: JSlhZPyV -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0