June 2018 - ghc-tickets

[GHC] #14317: Solve Coercible constraints over type constructors
by GHC 04 Jun '18

04 Jun '18

#14317: Solve Coercible constraints over type constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- The core question is, could `fails` type check? {{{#!hs import Data.Type.Coercion works :: Identity a `Coercion` Compose Identity Identity a works = Coercion -- • Couldn't match representation of type ‘Identity’ -- with that of ‘Compose Identity Identity’ -- arising from a use of ‘Coercion’ -- • In the expression: -- Coercion :: Identity `Coercion` Compose Identity Identity fails :: Identity `Coercion` Compose Identity Identity fails = Coercion }}} ---- This arises from playing with [https://duplode.github.io/posts/traversable-a-remix.html Traversable: A Remix]. Given `coerce :: Compose Identity Identity ~> Identity` I wanted to capture that `id1` and `id2` are actually the same arrow (up to representation) {{{#!hs (<%<) :: (Functor f, Functor g) => (b -> g c) -> (a -> f b) -> (a -> Compose f g c) g <%< f = Compose . fmap g . f id1 :: a -> Identity a id1 = Identity id2 :: a -> Compose Identity Identity a id2 = Identity <%< Identity }}} So I define {{{#!hs data F :: (k -> Type) -> (Type -> k -> Type) where MkF :: Coercible f f' => (a -> f' b) -> F f a b id1F :: Coercible Identity f => F f a a id1F = MkF id1 id2F :: Coercible (Compose Identity Identity) f => F f b b id2F = MkF id2 }}} but we can not unify the types of `id1F` and `id2F`. Does this require quantified class constraints? I'm not sure where they would go -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #2893: Implement "Quantified constraints" proposal
by GHC 04 Jun '18

04 Jun '18

#2893: Implement "Quantified constraints" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5927 | Differential Rev(s): Phab:D4724 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"7df589608abb178efd6499ee705ba4eebd0cf0d1/ghc" 7df5896/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7df589608abb178efd6499ee705ba4eebd0cf0d1" Implement QuantifiedConstraints We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints which in turn contains a link to the GHC Proposal where the change is specified. Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * Define a type TcRnTypes.QCInst, which holds a given quantified constraint in the inert set * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst], which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * topReactionsStage calls doTopReactOther for CIrredCan and CTyEqCan, so they can try to react with any given quantified constraints (TcInteract.matchLocalInst) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Some other related refactoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Move SCC on evidence bindings to post-desugaring, which fixed #14735, and is generally nicer anyway because we can use existing CoreSyn free-var functions. (Quantified constraints made the free-vars of an ev-term a bit more complicated.) * In LookupInstResult, replace GenInst with OneInst and NotSure, using the latter for multiple matches and/or one or more unifiers }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2893#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5927: A type-level "implies" constraint on Constraints
by GHC 04 Jun '18

04 Jun '18

#5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"7df589608abb178efd6499ee705ba4eebd0cf0d1/ghc" 7df5896/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7df589608abb178efd6499ee705ba4eebd0cf0d1" Implement QuantifiedConstraints We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints which in turn contains a link to the GHC Proposal where the change is specified. Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * Define a type TcRnTypes.QCInst, which holds a given quantified constraint in the inert set * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst], which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * topReactionsStage calls doTopReactOther for CIrredCan and CTyEqCan, so they can try to react with any given quantified constraints (TcInteract.matchLocalInst) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Some other related refactoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Move SCC on evidence bindings to post-desugaring, which fixed #14735, and is generally nicer anyway because we can use existing CoreSyn free-var functions. (Quantified constraints made the free-vars of an ev-term a bit more complicated.) * In LookupInstResult, replace GenInst with OneInst and NotSure, using the latter for multiple matches and/or one or more unifiers }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5927#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15222: T14547 is broken
by GHC 04 Jun '18

04 Jun '18

#15222: T14547 is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- It fails with: {{{ 10 + 11 +T14547.hs:14:9: warning: [-Wincomplete-patterns (in -Wextra)] 12 + Pattern match(es) are non-exhaustive 13 + In an equation for ‘foo’: Patterns not matched: [] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15222> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 04 Jun '18

04 Jun '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): A program that might run slower without the state hack is {{{ f :: Char -> IO () f 'x' = return () f c = putChar c }}} Now call that `f` many times. Without the state hack I think it'll have arity 1, returning a lambda that does the I/O. We must find out what happens with fasta, yes, but what are the perf results from nofib? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 04 Jun '18

04 Jun '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The correctness issue is very concerning (especially given that this is a rather vanilla program). I would say that this deserves its own ticket. Let's focus on that before turning our attention to the performance issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15224: Add -fwan-sum-type-partial-field-accessor
by GHC 04 Jun '18

04 Jun '18

#15224: Add -fwan-sum-type-partial-field-accessor -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- This a a new warning flag that would be off by default and warns when a sum type is defined with field accessors that are partial. For an example of something that would trigger the warning: {{{#!hs data Option a = Some { getSome :: a } | None }}} In production quality Haskell code it usually desirable to outright ban partial functions like `head`, `fromJust` etc by use of a custom prelude. Unfortunately partial functions can still sneak into a code base via field accessors in sum types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 04 Jun '18

04 Jun '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Ran a few test, and I'm getting perplexing results. First of all, a full GHC build from scratch, with `-fno-state-hack` everywhere, gives mixed results: Regular profiling build: {{{ real 66m1.181s user 118m55.812s sys 6m9.724s }}} Profiling build with `-fno-state-hack` enabled: {{{ real 66m25.030s user 119m48.580s sys 6m7.568s }}} So the difference is small, `real` and `sys` (which, I believe, is what counts) slightly in favor of removing the state hack, `user` in favor of keeping it. I've also done `nofib` runs with both compilers, also enabling / disabling the state hack accordingly; however it turns out that disabling the state hack causes `nofib` to fail: {{{ ------------------------------------------------------------------------ == make all --no-print-directory; in /home/tobias/well-typed/devel/ghc/HEAD/nofib/shootout/fasta ------------------------------------------------------------------------ HC = /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring RUNTEST_OPTS = -ghc-timing ==nofib== fasta: time to compile Main follows... /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 -O2 -Rghc- timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring -c Main.hs -o Main.o Main.hs:30:1: warning: [-Wtabs] Tab character found here, and in 13 further locations. Please use spaces instead. | 30 | let !k = min modulus (floor (fromIntegral modulus * (p::Float) + 1)) | ^^^^^^^^ <<ghc: 401958512 bytes, 72 GCs, 10720054/28796976 avg/max bytes residency (6 samples), 61M in use, 0.001 INIT (0.001 elapsed), 0.342 MUT (0.420 elapsed), 0.240 GC (0.238 elapsed) :ghc>> ==nofib== fasta: size of Main.o follows... text data bss dec hex filename 7245 2624 0 9869 268d Main.o ==nofib== fasta: time to link fasta follows... <<ghc: 49626024 bytes, 45 GCs, 1356153/2672728 avg/max bytes residency (5 samples), 8M in use, 0.001 INIT (0.001 elapsed), 0.025 MUT (0.468 elapsed), 0.060 GC (0.060 elapsed) :ghc>> ==nofib== fasta: size of fasta follows... text data bss dec hex filename 708996 127712 16232 852940 d03cc fasta ==nofib== fasta: time to run fasta follows... ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; 0.43user 0.02system 0:00.45elapsed 99%CPU (0avgtext+0avgdata 4824maxresident)k 0inputs+49656outputs (0major+608minor)pagefaults 0swaps ././fasta 2500000 < /dev/null expected stdout not matched by reality --- fasta.stdout 2018-06-02 03:00:43.887025433 +0200 +++ /tmp/runtest4673.1 2018-06-02 03:09:19.651755697 +0200 @@ -83337,333335 +83337,333335 @@ cttBtatcatatgctaKggNcataaaSatgtaaaDcDRtBggDtctttataattcBgtcg -tactDtDagcctatttSVHtHttKtgtHMaSattgWaHKHttttagacatWatgtRgaaa -NtactMcSMtYtcMgRtacttctWBacgaaatatagScDtttgaagacacatagtVgYgt -cattHWtMMWcStgttaggKtSgaYaaccWStcgBttgcgaMttBYatcWtgacaYcaga -gtaBDtRacttttcWatMttDBcatWtatcttactaBgaYtcttgttttttttYaaScYa -HgtgttNtSatcMtcVaaaStccRcctDaataataStcYtRDSaMtDttgttSagtRRca #### ~3.1 million similar lines follow #### -taatataagctgcgccaggggatttttccagatcatctggcctgtgtatatgttcaaatc +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt #### ~208k identical lines follow +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt taatagccgagagaaattac ../../mk/target.mk:101: recipe for target 'runtests' failed make[2]: *** [runtests] Error 1 Failed making all in fasta: 1 ../mk/ghc-recurse.mk:65: recipe for target 'all' failed make[1]: *** [all] Error 1 Failed making all in shootout: 1 mk/ghc-recurse.mk:65: recipe for target 'all' failed make: *** [all] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15223: Serialising Names using the GHC API is not possible
by GHC 04 Jun '18

04 Jun '18

#15223: Serialising Names using the GHC API is not possible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4782 | Wiki Page: -------------------------------------+------------------------------------- In order to serialise a `Name` using `Binary` you have to initialise `UserData`. This isn't possible because the constructors necessary to write the symbol table and dictionary are not exported. However, it turns out to be easy to extract the necessary logic and provide two nice wrapper functions to provide this functionality. This makes it possible to serialise Names when writing source plugins for instance. https://phabricator.haskell.org/D4782 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable
by GHC 03 Jun '18

03 Jun '18

#4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgillespie): Agreed; however, GHC does display the same contradictory message with hidden packages: {{{ Prelude> :m + Data.Map <no location info>: error: Could not find module ‘Data.Map’ It is a member of the hidden package ‘containers-0.5.11.0’. You can run ‘:set -package containers’ to expose it. (Note: this unloads all the modules in the current scope.) }}} I think it would make sense to use the same language for both scenarios. I can either update both, or leave them both the same. What do you think? In the meantime, I'm going to go ahead and submit a review so someone can start reviewing it -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4806#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0