January 2017 - ghc-tickets

[GHC] #12025: Order of constraints forced (in pattern synonyms, type classes in comments)
by GHC 10 Sep '17

10 Sep '17

#12025: Order of constraints forced (in pattern synonyms, type classes in comments) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 11513, 10928 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ever since `TypeApplications` the order of quantification matters. It seems there are some places where the user has no control over the order: {{{#!hs data A a where X :: A [xxx] pattern X' :: forall t. () => forall xxx. t ~ [xxx] => A t pattern X' = X }}} This quantifies the universal `t` and the existential `xxx`.. but in this case `t` is constrained to equal `[xxx]` so when we supply our first type (the universal `t`) it is forced to be of the form `[a]`. Then the existential is forced to equal `a` (there is currently no way to express this without a type annotation `X' @[t] @t :: A [t]`, see ticket #11385 to allow `X' @[_t] @_t`, for this ticket the equality is inherent in `X` so it's no big deal). This means that the first argument really doesn't give any further information but it seems impossible to reorder the existential type before the universal. This either forces the user to supply a dummy type: {{{#!hs X' @_ @ActualType }}} or to write `[ActualType]` explicitly {{{#!hs X' @[ActualType] X' @[ActualType] @ActualType X' @[_] @ActualType }}} This may be a bigger inconvenience than it may seem: the return type can be more complicated `A (B (C a))` and it requires the user to look it up. `X' @_ @ActualType` feels like bad library design, especially as the number of existential variables grows and the user has to remember how many underscores to provide. See also ticket:10928#comment:5 Keep in mind that this usage will be common, since the more obvious (see ticket:10928#comment:16) {{{#!hs pattern X'' :: forall xxx. A [xxx] pattern X'' = X }}} cannot match against a type `A a` {{{#!hs -- Works foo :: A a -> ... foo X' = ... -- Doesn't bar :: A a -> ... bar X'' = ... }}} Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12025> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9661: Branchless ==# is compiled to branchy code
by GHC 08 Sep '17

08 Sep '17

#9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This started as a comment on #6135, but Jan Stolarek requested that I file a separate report. The branchless tests `<#`, `>#`, `<=#`, and `>=#`, and their wordy cousins, seem to work properly, but `==#` and `eqWord#` don't. If I write {{{#!hs foo x = tagToEnum# ((x <# 3#) `orI#` (x ># 100#) `orI#` (x ==# 12#) `orI#` (x ==# 15#)) }}} I get (in 7.8.3 and in 7.9) {{{#!hs IsDigit.foo :: GHC.Prim.Int# -> GHC.Types.Bool [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <S,1*U>, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (x3_a2if [Occ=Once!] :: GHC.Prim.Int#) -> case x3_a2if of wild_Xe { __DEFAULT -> GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.orI# (GHC.Prim.<# wild_Xe 3) (GHC.Prim.># wild_Xe 100)); 12 -> GHC.Types.True; 15 -> GHC.Types.True }}] IsDigit.foo = \ (x3_a2if :: GHC.Prim.Int#) -> case x3_a2if of wild_Xe { __DEFAULT -> GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.orI# (GHC.Prim.<# wild_Xe 3) (GHC.Prim.># wild_Xe 100)); 12 -> GHC.Types.True; 15 -> GHC.Types.True }}} and branching assembly to match. Jan Stolarek indicates this is probably a problem with constant folding. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9661> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #10365: Make Semigroup as a superclass of Monoid
by GHC 07 Sep '17

07 Sep '17

#10365: Make Semigroup as a superclass of Monoid -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a -superclass-of-Monoid-td5767835.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types
by GHC 06 Sep '17

06 Sep '17

#9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When we see `m >>= (\_ -> n)` with a type that admits an optimized `>>` or `<$`, we should try to take advantage of that. I don't currently know if this applies to any types under "GHC HQ" control. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10328: Control.Monad exports lead to weird Haddocks
by GHC 06 Sep '17

06 Sep '17

#10328: Control.Monad exports lead to weird Haddocks -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: Documentation Keywords: | bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `Control.Monad` exports, and therefore documents, the `Functor` class (but only the `fmap` member) and the `Monad` class. It does not export, and therefore does not document, the `Applicative` class. This is all pretty weird. Since `Functor` is in the prelude (and probably most/all alternate preludes), is there actually a reason to export it from `Control.Monad`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10328> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9756: Warn about unnecessary unsafeCoerce
by GHC 06 Sep '17

06 Sep '17

#9756: Warn about unnecessary unsafeCoerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `unsafeCoerce` has been around a lot longer than `coerce`, so older code tends to use it even if `coerce` could do the job. It would be nice if the type checker could produce a warning when it detected such a situation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13182: Rethinking dataToTag#
by GHC 06 Sep '17

06 Sep '17

#13182: Rethinking dataToTag# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We currently use a primop `dataToTag#` that requires some careful handling because it can only be applied to something that has already been evaluated. We (now) mark it `can_fail` to prevent it from floating out, and then add a fix-up pass in CorePrep just in case things went wrong. Could we do something simpler? Suppose we had {{{#!hs -- The real primop, preferably not exported from *anywhere*, but at least documented as never to be used outside GHC. secretDataToTag# :: a -> Int# -- A wired-in safe version dataToTag# :: a -> Int# dataToTag# !a = secretDataToTag# a {-# NOINLINE dataToTag# #-} }}} Then `dataToTag#` could be inlined in CorePrep, just like `runRW#`. === Questions === How would this interact with float out? It should be perfectly safe to float out when its argument is known to be forced, but it seems likely we'll run into let/app invariant failures. What RULES do we (or should we) have for `dataToTag#`? How will this change affect them? My vague recollection is that we don't have any, but it would be pretty nice to apply something equivalent to case-of-known- constructor. Whenever `dataToTag#` is applied to a known constructor, we should be able to evaluate it. The earlier we do this the better it will inform simplification. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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

[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