September 2017 - ghc-tickets

[GHC] #14131: Difference between newtype and newtype instance
by GHC 05 Sep '17

05 Sep '17

#14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- This works {{{#!hs {-# Language RankNTypes, PolyKinds, GADTs #-} newtype Nat :: (k -> *) -> (k -> *) -> * where Nat :: (forall xx. f xx -> g xx) -> Nat f g }}} but this {{{#!hs {-# Language RankNTypes, PolyKinds, GADTs, TypeFamilies #-} data family Nat :: k -> k -> * newtype instance Nat :: (k -> *) -> (k -> *) -> * where Nat :: (forall xx. f xx -> g xx) -> Nat f g }}} fails on GHC 8.3.20170815, and requires a `forall k.` to work {{{ $ ./ghc-stage2 -ignore-dot-ghci --interactive /tmp/kind.hs GHCi, version 8.3.20170815: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/kind.hs, interpreted ) /tmp/kind.hs:5:26: error: Not in scope: type variable ‘k’ | 5 | newtype instance Nat :: (k -> *) -> (k -> *) -> * where | ^ /tmp/kind.hs:5:38: error: Not in scope: type variable ‘k’ | 5 | newtype instance Nat :: (k -> *) -> (k -> *) -> * where | ^ Failed, 0 modules loaded. }}} Related to #12369? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #13985: GHC 8.0 regression: ‘k’ is not in scope during type checking, but it passed the renamer
by GHC 05 Sep '17

05 Sep '17

#13985: GHC 8.0 regression: ‘k’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13738 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Proxy data family Fam data instance Fam = MkFam (forall (a :: k). Proxy a) }}} On GHC 8.0.1, 8.0.2, 8.2.1, and HEAD, this fails with a GHC internal error: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:9:41: error: • GHC internal error: ‘k’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r1vy :-> APromotionErr FamDataConPE] • In the kind ‘k’ In the type ‘(forall (a :: k). Proxy a)’ In the definition of data constructor ‘MkFam’ | 9 | data instance Fam = MkFam (forall (a :: k). Proxy a) | ^ }}} This is a regression, since on GHC 7.10.3, it did not crash: {{{ $ /opt/ghc/7.10.3/bin/ghci Bug.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:9:21: Data constructor ‘MkFam’ has existential type variables, a context, or a specialised result type MkFam :: forall (k :: BOX). (forall (k :: BOX) (a :: k). Proxy a) -> Fam (Use ExistentialQuantification or GADTs to allow this) In the definition of data constructor ‘MkFam’ In the data instance declaration for ‘Fam’ }}} This smells like #13738, but no `TypeApplications` are involved here, so I decided to open a separate ticket to be safe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13985> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9574: GHC Panic: No Skolem Info
by GHC 05 Sep '17

05 Sep '17

#9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | 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: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC 7.8.3 and from git both panic with Couldn't match kind ‘o1’ with ‘(,) o o’ ‘o1’ is untouchable inside the constraints (Object (c :><: c) a) bound by a type expected by the context: Object (c :><: c) a => Tagged a (c (FMap (ProductF c) a) (FMap (Proj2 c c) a)) at Product.hs:35:9-15ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140908 for x86_64-unknown-linux): No skolem info: o1_a6XS I have not yet attempted to reduce the problem at all. The offending code is the use of fmap here: {{{#!hs proj2 :: forall (c :: o -> o -> *). ProductCategory c => NatTr (c :><: c) c (ProductF c) (Proj2 c c) proj2 = NatTr t where NatTr t = fmap (CompF Proj2 IdentityF) e e :: NatTr (c :><: c) (c :><: c) (Comp ('KProxy :: KProxy o) (Diag c) (ProductF c)) (IdentityF (c :><: c)) e = counit }}} fmap is defined as {{{#!hs fmap :: forall f (a :: o1) (b :: o1). Functor f ('KProxy :: KProxy (o1 -> o2)) => f -> Domain f a b -> Codomain f (FMap f a :: o2) (FMap f b :: o2) fmap _ = proxy morphMap (Proxy :: Proxy f) }}} while CompF is defined by {{{#!hs data CompF f g (k :: KProxy (o3 -> o4, o1 -> o2)) where CompF :: (Functor f ('KProxy :: KProxy (o3 -> o4)), Functor g ('KProxy :: KProxy (o1 -> o2))) => f -> g -> CompF f g ('KProxy :: KProxy (o3 -> o4, o1 -> o2)) }}} This makes some sense because there is a functional dependency between the functor and the kind proxy. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7938: Unbound kind variable can appear in RHS of associated type
by GHC 05 Sep '17

05 Sep '17

#7938: Unbound kind variable can appear in RHS of associated type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC accepts | Test Case: indexed- invalid program | types/should_fail/T7938 Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Ryan Scott <ryan.gl.scott@…>): In [changeset:"0829821a6b886788a3ba6989e57e25a037bb6d05/ghc" 0829821a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0829821a6b886788a3ba6989e57e25a037bb6d05" Implicitly bind kind variables in type family instance RHSes when it's sensible Summary: Before, there was a discrepancy in how GHC renamed type synonyms as opposed to type family instances. That is, GHC would accept definitions like this one: ```lang=haskell type T = (Nothing :: Maybe a) ``` However, it would not accept a very similar type family instance: ```lang=haskell type family T :: Maybe a type instance T = (Nothing :: Maybe a) ``` The primary goal of this patch is to bring the renaming of type family instances up to par with that of type synonyms, causing the latter definition to be accepted, and fixing #14131. In particular, we now allow kind variables on the right-hand sides of type (and data) family instances to be //implicitly// bound by LHS type (or kind) patterns (as opposed to type variables, which must always be explicitly bound by LHS type patterns only). As a consequence, this allows programs reported in #7938 and #9574 to typecheck, whereas before they would have been rejected. Implementation-wise, there isn't much trickery involved in making this happen. We simply need to bind additional kind variables from the RHS of a type family in the right place (in particular, see `RnSource.rnFamInstEqn`, which has undergone a minor facelift). While doing this has the upside of fixing #14131, it also made it easier to trigger #13985, so I decided to fix that while I was in town. This was accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13985, #14131 Differential Revision: https://phabricator.haskell.org/D3872 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7938#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13988: GADT constructor with kind equality constraint quantifies unused existential type variables
by GHC 05 Sep '17

05 Sep '17

#13988: GADT constructor with kind equality constraint quantifies unused existential type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Reproducible with GHC 8.0.1., 8.0.2, 8.2.1, or HEAD (but I'll use GHC 8.2.1 to show the results of `:type +v`): {{{ $ /opt/ghc/8.2.1/bin/ghci GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeInType -XGADTs -fprint-explicit-foralls λ> import Data.Kind λ> data Foo (a :: k) where MkFoo :: (k ~ Type) => Foo (a :: k) λ> :type +v MkFoo MkFoo :: forall k1 (a :: k1) k2 (k3 :: k2). k1 ~ * => Foo a }}} Note that `MkFoo` quantifies two extra existential type variables, `k2` and `k3` which are completely unused! Note that this does not occur if the `MkFoo` constructor uses an explicit `forall`: {{{ λ> :set -XScopedTypeVariables λ> data Foo (a :: k) where MkFoo :: forall k (a :: k). (k ~ Type) => Foo (a :: k) λ> :type +v MkFoo MkFoo :: forall k (a :: k). k ~ * => Foo a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13988> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14181: make test WAY=xxx broken
by GHC 05 Sep '17

05 Sep '17

#14181: make test WAY=xxx broken -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems like running {{{ make test WAY=someWay }}} is broken. Looking at the `runtest.py`, it seems that we parse the arguments to the test driver before reading the configuration file (e.g. `config/ghc`), and thus the `--way` flags arguments are not available. E.g. the way options get populated, once the `--config-file` argument is processed. But the argument parser seems to be eager and as such the handling of the `--config-file` happens *after* all of the arguments have been parsed. Therefore the set of available `--way`s are always the empty set. I don't know if python2 was lazy here. But with `python3` using `--way` seems impossible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14181> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13105: Allow type families in RuntimeReps
by GHC 04 Sep '17

04 Sep '17

#13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- Conal Elliott provided me with this puzzle: {{{ type family RepRep a ∷ RuntimeRep class HasRep a where type Rep a ∷ TYPE (RepRep a) repr ∷ a → Rep a abst ∷ Rep a → a type instance RepRep Int = IntRep instance HasRep Int where type Rep Int = Int# abst n = I# n repr (I# n) = n }}} I think we should accept. However, doing so (even with my solution to #12809 complete) is hard, because we frequently consult a kind in order to determine a runtime representation. When that kind is `TYPE (RepRep Int)`, the code generator throws up its arms in despair. The solution here is either to teach the code generator how to normalise types (requiring propagating the `FamInstEnvs`) or to do a whole-program transformation at some point (zonker? desugarer? maybe we can wait until !CorePrep or even unarisation?) to change ids whose types have kinds like `TYPE (RepRep Int)` into ids with types with kinds like `TYPE IntRep`. But I don't want to let this hold me up at the moment, so I'm posting here as a reminder to revisit this problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12708: RFC: Representation polymorphic Num
by GHC 04 Sep '17

04 Sep '17

#12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- I can create a GHC proposal for this but I need a sanity check first {{{#!hs import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: Type k) where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a instance Num Int# where (+) :: Int# -> Int# -> Int# (+) = (+#) (-) :: Int# -> Int# -> Int# (-) = (-#) (*) :: Int# -> Int# -> Int# (*) = (*#) negate :: Int# -> Int# negate = negateInt# ... fromInteger :: Integer -> Int# fromInteger (fromInteger -> I# int) = int instance Num Double# where (+) :: Double# -> Double# -> Double# (+) = (+##) (-) :: Double# -> Double# -> Double# (-) = (-##) (*) :: Double# -> Double# -> Double# (*) = (*##) negate :: Double# -> Double# negate = negateDouble# ... fromInteger :: Integer -> Double# fromInteger (fromInteger -> D# dbl) = dbl }}} Note how the `fromInteger` views aren't qualified? That's because we can branch on the kind and all of a sudden, all instances of old `Num` are instances of our `Num` {{{#!hs instance P.Num a => Num (a :: Type) where (+) = (P.+) (-) = (P.-) (*) = (P.*) negate = P.negate abs = P.abs signum = P.signum fromInteger = P.fromInteger }}} ---- Same with `Show` etc. etc. {{{#!hs class Show (a :: TYPE k) where show :: (a :: TYPE k) -> String instance P.Show a => Show (a :: Type) where show :: (a :: Type) -> String show = P.show instance Show Int# where show :: Int# -> String show int = show (I# int) instance Show Double# where show :: Double# -> String show dbl = show (D# dbl) }}} ---- What effects would this have? They are even printed the same by default {{{#!hs >>> :kind Prelude.Num Prelude.Num :: * -> Constraint >>> :kind Main.Num Main.Num :: * -> Constraint >>> :set -fprint-explicit-runtime-reps >>> :kind Main.Num Main.Num :: TYPE k -> Constraint }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #14183: ghc.exe: addLibrarySearchPath error
by GHC 04 Sep '17

04 Sep '17

#14183: ghc.exe: addLibrarySearchPath error ----------------------------------------+--------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Recently I've removed Haskell Platform 8.0.1 and installed new Platform 8.2.1 Since then, when compiling a module GHC sometimes spits the following messages: {{{ ghc.exe: addLibrarySearchPath: C:\Program Files\Haskell Platform\8.0.1\mingw\lib (Win32 error 3): The system cannot find the path specified. }}} dozens of times in a row. But the compilation succeeds. The directory `C:\Program Files\Haskell Platform\8.0.1\` doesn't exist on my machine. I haven't figured out when exactly this happens but it seems to happen only when the module has Template Haskell splices in it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14184: Examples with language extensions
by GHC 03 Sep '17

03 Sep '17

#14184: Examples with language extensions -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- Are we okay with examples in the GHC user guide uses language extensions? The documentation has [https://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#record-constructors this code] {{{#!hs inc :: Counter a -> Counter a inc (NewCounter x i d t) = NewCounter { _this = i x, _inc = i, _display = d, tag = t } }}} which could be written {{{#!hs inc :: Counter a -> Counter a inc NewCounter{..} = NewCounter{ _this = _inc _this, .. } }}} if we're okay with that tradeoff. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2