December 2016 - ghc-tickets

[GHC] #12524: RFC: Allow prefixing result evaluated at GHCi prompt
by GHC 23 Feb '18

23 Feb '18

#12524: RFC: Allow prefixing result evaluated at GHCi prompt -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- Similar to `prompt`, `prompt-cont` (previously `prompt2`): allowing users to supply a prefix to evaluation results with `result` has two use cases I can think of {{{ :set prompt " ghci> " :set prompt-cont " ghci| " :set result " " }}} the desired outcome would be `↓` as indented code for IRC, also reddit code format: {{{ ghci> 1 + 2 + 3 6 ghci> reverse "hello" "olleh" }}} ---- The other case came from [https://twitter.com/rightfold/status/767301255140179968 this tweet] {{{ :set prompt "" :set result "-- " }}} {{{ 1 + 2 + 3 -- 6 reverse "hello" -- "olleh" }}} This can be copied/pasted back to a separate GHCi session where the result is ignored. ---- I haven't seen this feature in any other repl, I'm not sure if this would see much use. This wouldn't work with IO actions without some magic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11285: Static linking is really slow sometimes
by GHC 20 Feb '18

20 Feb '18

#11285: Static linking is really slow sometimes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- I'm testing on Cabal `Setup.hs`, which links against Cabal. On a beefy machine with many cores and lots of RAM, I see a x2 regression in linking time from GHC 7.10.2 to GHC 8.0 (a recent HEAD) using GNU ld (not gold): {{{ [ezyang@hs01 ezyang]$ rm A; time ghc --make A.hs -fforce-recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m1.273s user 0m0.990s sys 0m0.210s [ezyang@hs01 ezyang]$ rm A; time ghc-8.0/usr/bin/ghc --make A.hs -fforce- recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m3.270s user 0m2.727s sys 0m0.523s }}} On a puny eight year-old laptop, I see a x2 regression from 7.6 to 7.10 (with not much change with 8.0) {{{ ezyang@sabre:~$ rm A; time ghc --make -O0 A.hs -fforce-recomp rm: cannot remove ‘A’: No such file or directory [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m3.058s user 0m1.860s sys 0m1.164s ezyang@sabre:~$ rm A; time ghc-7.10 --make -O0 A.hs -fforce-recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m7.139s user 0m4.616s sys 0m2.488s }}} There must be something which is causing the linker to run slowly in one case, and quickly in the other. It would be really good to figure out what this is. Slow linking is NOT NICE. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11427: TypeSynonyms not deduced
by GHC 20 Feb '18

20 Feb '18

#11427: TypeSynonyms not deduced -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- {{{ class (AllF f xs, SListI xs) => All (f :: k -> Constraint) (xs :: [k]) instance #if __GLASGOW_HASKELL__ >= 710 {-# OVERLAPPING #-} #endif All SListI xss => SingI (xss :: [[k]]) where sing = sList }}} fails with {{{ • Could not deduce (SListI xss) arising from the superclasses of an instance declaration from the context: All SListI xss bound by the instance declaration at src/Generics/SOP/Constraint.hs:141:3-40 • In the instance declaration for ‘SingI xss’ }}} See https://travis-ci.org/well-typed/generics-sop/jobs/102388817 and https://github.com/phadej/generics-sop/tree/ghc-8.0.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11791: Remove the `isInlinePragma prag` test
by GHC 19 Feb '18

19 Feb '18

#11791: Remove the `isInlinePragma prag` test -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11781, #5928 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin off of tickjet:11781#comment:9, where simonpjs writes: > What is more mysterious to me is why the unfolding for `$fApplicativeIO_$c*>` doesn't have `bindIO`, and then `bindIO` inlined into it, which would allow a cascade of further improvements, which would, I think, produce essentially the same code as `thenIO`. > > The offending corner is this > {{{ > active_unfolding_gentle id > = isInlinePragma prag -- WHY?? > && isEarlyActive (inlinePragmaActivation prag) > }}} > So I tried removing the `isInlinePragma prag` test, and indeed the code becomes identical. > > Conclusion: > * I'd love to make the above change to `active_unfolding_gentle` and see if any other performance numbers budge. I doubt that anything will change a lot -- it really only affects whether optimisation happens before or after inlining -- but it should improve compiler performance a bit for that very reason. This could be a separate ticket > > Incidentally, see #5928 which is somewhat related. This ticket tracks that idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9429: Alternative to type family Any
by GHC 18 Feb '18

18 Feb '18

#9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 9097, 9380 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In GHC HEAD, `Any` is no longer a datatype. There are good reasons for this change, one of which was explained in #9097, the original ticket, and another in #9380. Unfortunately, a casualty of this change is that it is no longer easy to generalize the [https://hackage.haskell.org/package/rank1dynamic|rank1dynamic package] to rank-1 types with type variables of arbitrary kind (not just `*`). We submitted a way to do so [here], that exploits the fact that `Any` has the very magical property of inhabiting *all* kinds, including closed ones. This works for GHC 7.8, but won't work in HEAD, because we require that there exists a `Typeable` instance for `Any`, just as there are `Typeable` instances for any other type one wishes to have instances for. The reason is that now that `Any` is a type family, `Any` is no longer a legal instance head. There are several possible solutions that I see: * while it's clearly dangerous for the compiler to be inserting the old `Any` during typechecking from the moment that we have computation in types over closed kinds, we may still want the old `Any`, say under a different name, as a backdoor. It wouldn't be used by the compiler during type checking - only by packages such as rank1dynamic. I believe that furthermore, if we restrict the old `Any` to not inhabit closed kinds, then none of the problems cited in the above tickets arise. * Instead of making the new `Any` a type family, keep it a datatype, but ban it from inhabiting closed kinds. I don't know if such an `Any` would be sufficient for the purposes of GHC, however. * Hardwire a `Typeable` instance for the `Any` type family (not sure if this makes sense). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #8258: GHC accepts `data Foo where` in H2010 mode
by GHC 14 Feb '18

14 Feb '18

#8258: GHC accepts `data Foo where` in H2010 mode --------------------------+------------------------------------------------ Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 7.8.1 Component: | Version: 7.0.4 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts invalid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ According to the Haskell2010 report, The grammar productions relevant for `data` declarations are the following: {{{ topdecl → data [context =>] simpletype [= constrs] [deriving] }}} (from [http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2 4.2.1 Algebraic Datatype Declarations]) However, GHC 7.0.4/7.4.2/7.6.3/HEAD all happily compile the following Haskell module without any warning when using `-XHaskell2010 -Wall`, even though this is not valid Haskell2010 afaik: {{{#!hs module Foo where data Foo where }}} The trailing `where` in the `data` declaration is not valid Haskell2010 (without language extensions such as `GADT`). At the very least, this divergence from the Haskell Report should be mentioned in [http://www.haskell.org/ghc/docs/latest/html/users_guide /bugs-and-infelicities.html#haskell-standards-divergence 14.1.1. Divergence from Haskell 98 and Haskell 2010]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9269: Type families returning quantified types
by GHC 14 Feb '18

14 Feb '18

#9269: Type families returning quantified types ------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Is there a fundamental reason for not being able to use quantification in a type family? I'd very much like to be able to do it, obviously turning on RankNTypes if necessary. I'm looking for things like this: {{{#!haskell type family Foo (x :: Bool) where Foo True = forall a. [a] Foo False = () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9269> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12422: Add decidable equality class
by GHC 14 Feb '18

14 Feb '18

#12422: Add decidable equality class -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | 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: -------------------------------------+------------------------------------- Currently, we have a `TestEquality` class {{{#!hs class TestEquality f where testEquality :: f a -> f b -> Maybe (a :~: b) }}} It would be nice to add a class for fully decidable equality. There are a few options, but this one gets to the point rather quickly: {{{#!hs data EqDec a b where NotEqual :: (forall c . a :~: b -> c) -> EqDec a b Equal :: EqDec a a class DecEq f where decEq :: f a -> f b -> EqDec a b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12262: Binary output is not deterministic
by GHC 07 Feb '18

07 Feb '18

#12262: Binary output is not deterministic -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- The goal of DeterministicBuilds (#4012) was to get ABI-compatible binaries given the same sources, flags and the environment. There's a stronger goal of getting bit-for-bit identical binaries and this ticket will track that. Known causes of binary nondeterminism: * Unique comparison * Uniques converted to strings for symbol names * everything else from #4012 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12685: getNumProcessors semantics dont match documentation
by GHC 06 Feb '18

06 Feb '18

#12685: getNumProcessors semantics dont match documentation ----------------------------------------+--------------------------------- Reporter: Llgn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Hi, The documentation of getNumProcessors says : "Returns the number of CPUs that the machine has", but it is true only for program compiled with -threaded option. https://hackage.haskell.org/package/base-4.9.0.0/docs/GHC-Conc- Sync.html#v:getNumProcessors I guess the documentation is just misleading. Or is it a bug ? Regards -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3