June 2017 - ghc-tickets

[GHC] #12160: MonadFail instance for (Either String)?
by GHC 26 Oct '18

26 Oct '18

#12160: MonadFail instance for (Either String)? -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | 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 think one of the cool things about breaking out `MonadFail` would be the opportunity to introduce an instance for `Either String`, which isn’t possible to do with plain `Monad` without overlapping instances. The instance itself would be completely trivial: {{{#!hs instance MonadFail (Either String) where fail = Left }}} The only possible reason to ''not'' do this, as far as I can tell, would be because it requires `FlexibleInstances`. This already seems to be used for a few instances in `base`, and it seems like it would be extremely useful, so I would really appreciate if such an instance was defined. I’d be happy to submit a patch to add it, but I wasn’t sure if this would be an uncontroversial change or not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12160> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #12677: Type equality in constraint not used?
by GHC 24 Oct '18

24 Oct '18

#12677: Type equality in constraint not used? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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: -------------------------------------+------------------------------------- {{{#!hs data TyRep :: forall k. k -> Type where TyInt :: TyRep Int TyBool :: TyRep Bool TyMaybe :: TyRep Maybe TyApp :: TyRep f -> TyRep x -> TyRep (f x) }}} This is allowed: {{{#!hs zero :: TypeRep (a :: Type) -> a zero = undefined }}} but this is not {{{#!hs zero :: Type ~ k => TyRep (a :: k) -> a zero = undefined zero :: TyRep (a :: k) -> Type ~ k => a zero = undefined }}} {{{ tuHu.hs:20:35: error: … • Expected a type, but ‘a’ has kind ‘k’ • In the type signature: zero :: Type ~ k => R (a :: k) -> a Compilation failed. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12677> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13087: AlternativeLayoutRule breaks LambdaCase
by GHC 24 Oct '18

24 Oct '18

#13087: AlternativeLayoutRule breaks LambdaCase -------------------------------------+------------------------------------- Reporter: ohhellojoe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE AlternativeLayoutRule #-} {-# LANGUAGE LambdaCase #-} isOne :: Int -> Bool isOne = \case 1 -> True _ -> False main = return () }}} {{{ $ ghc test-case [1 of 1] Compiling Main ( test-case.hs, test-case.o ) test-case.hs:5:15: error: parse error on input ‘1’ }}} It compiles fine without the AlternativeLayoutRule extension. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10453: \case should trigger auto-multiline mode in ghci
by GHC 24 Oct '18

24 Oct '18

#10453: \case should trigger auto-multiline mode in ghci -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In ghci, most block heralds trigger the multiline mode when :set +m is on. However, \case does not (and should). Compare: {{{ Prelude> ($True) (\case Prelude| x -> x Prelude| ) True Prelude> ($True) $ \case <interactive>:11:11: Empty list of alternatives in case expression Use EmptyCase to allow this }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12119: Can't create injective type family equation with TypeError as the RHS
by GHC 24 Oct '18

24 Oct '18

#12119: Can't create injective type family equation with TypeError as the RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple CustomTypeErrors, TypeFamilies, | Injective | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For the longest time, I've wanted to make a type family like this injective: {{{#!hs type family Foo (a :: *) :: * where Foo Bar = Int Foo Baz = Char }}} But the problem is that `Foo` is defined on //all// types of kind `*`, so the above definition is inherently non-injective. With the introduction of `TypeError`s, however, I thought I could rule out all other cases: {{{#!hs import GHC.TypeLits type family Foo (a :: *) = (r :: *) | r -> a where Foo Bar = Int Foo Baz = Char Foo _ = TypeError ('Text "boom") }}} But this doesn't work, sadly: {{{ Injective.hs:18:3: error: • Type family equations violate injectivity annotation: Foo Bar = Int -- Defined at Injective.hs:18:3 Foo _ = (TypeError ...) -- Defined at Injective.hs:20:3 • In the equations for closed type family ‘Foo’ In the type family declaration for ‘Foo’ Injective.hs:20:3: error: • Type family equation violates injectivity annotation. Type variable ‘_’ cannot be inferred from the right-hand side. In the type family equation: Foo _ = (TypeError ...) -- Defined at Injective.hs:20:3 • In the equations for closed type family ‘Foo’ In the type family declaration for ‘Foo’ Injective.hs:20:3: error: • Type family equation violates injectivity annotation. RHS of injective type family equation cannot be a type family: Foo _ = (TypeError ...) -- Defined at Injective.hs:20:3 • In the equations for closed type family ‘Foo’ In the type family declaration for ‘Foo’ }}} From GHC's perspective, `TypeError` is just another type family, so it thinks it violates injectivity. But should this be the case? After all, having the RHS of a type family equation being `TypeError` is, in my perspective, tantamount to making that type family undefined for those inputs. It seems like if we successfully conclude that `Foo a ~ Foo b` (and GHC hasn't blown up yet due to type erroring), we should be able to conclude that `a ~ b`. Could this be accomplished by simply adding a special case for `TypeError` in the injectivity checker? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12119> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11307: Regresssion: parsing type operators
by GHC 17 Oct '18

17 Oct '18

#11307: Regresssion: parsing type operators -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 7.10.3 will parse (but not type-check) the following {{{#!hs {-# LANGUAGE TypeOperators #-} type family (r1 :++: r2); infixr 5 :++: type instance r :++: Nil = r type instance r1 :++: r2 :> a = (r1 :++: r2) :> a }}} Current master (c7830bdb14e0a85a78617314156d101155fdf7aa) fails with {{{#!hs /tmp/Foo.hs:5:15: error: Malformed head of type or class declaration: r1 :++: r2 :> a }}} @simonpj comment on ghc-devs mailing list > `| type instance r1 :++: r2 :> a = (r1 :++: r2) :> a` > > What do you expect this to mean? I suppose you could hope that GHC will > unravel the fixity of :++: and :>, to determine whether you are giving an > instance for :++: or for :>? > > That sounds reasonable, but it's not trivial. > > Currently the LHS of a 'type instance' decl is ultimately a TyFamEqn, and > it looks like this: > > {{{#!hs > data TyFamEqn name pats > = TyFamEqn > { tfe_tycon :: Located name > , tfe_pats :: pats > , tfe_rhs :: LHsType name } > }}} > > So we've already decided (in the parser) what the type-function name is. > But we can't do that in this case, because the parser doesn't understand > fixity. > > To deal with this we'd need to change to > > {{{#!hs > data TyFamEqn name pats > = TyFamEqn > { tfe_lhs :: LHSType name > , tfe_rhs :: LHsType name } > }}} > > so that the LHS was just a type. Now the renamer can re-jiggle its > fixities in the usual way, and only in the type checker will we need to > decide exactly which type it's an instance of. Easy! > > This might be a good change to make! It's a bit like in ClsInstDecl, you'll > see that the instance cid_poly_ty is just a LHsSigType, i.e. not decomposed > into which class it is. > -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11307> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13600: surprising error message with bang pattern
by GHC 16 Oct '18

16 Oct '18

#13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- the following code {{{ f3 :: [Int] -> IO Int f3 x = return (sum x) f4 :: [Int] -> IO Int f4 !x = return (sum x) }}} gives `The type signature for ‘f4’ lacks an accompanying binding` for the second function (the two functions are exactly the same except for the added bang). I do not understand bang patterns well, but would expect a more instructive error message. without the type definition, the second function f4 compiles with the bang). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12430: TypeFamilyDependencies accepts invalid injectivity annotation
by GHC 16 Oct '18

16 Oct '18

#12430: TypeFamilyDependencies accepts invalid injectivity annotation -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code (depends on singletons-2.2): {{{#!hs {-# LANGUAGE TypeFamilies, DataKinds, PolyKinds, TypeOperators, KindSignatures, TypeInType, TypeFamilyDependencies, UndecidableInstances #-} module Bug where import Data.Kind (Type) import Data.Singletons.Prelude (Map, SndSym0) import GHC.TypeLits (Nat) data Payload = A | B newtype NewType a = NewType Int type NatList = [(Nat, Payload)] type StripNatList (natList :: NatList) = Map SndSym0 natList type family Family (natList :: NatList) = (r :: Type) | r -> natList where Family '[] = () Family xs = NewType (StripNatList xs) }}} Why GHC is okay with injectivity annotation for `Family`: `r -> natList`? These two types: {{{#!hs type Foo = Family '[ '(0, 'A), '(1, 'B)] type Bar = Family '[ '(0, 'A), '(0, 'B)] }}} are obviously map to the same type: {{{#!hs *Bug Data.Singletons.Prelude> :kind! Foo Foo :: * = NewType ('A :$$$ '['B]) *Bug Data.Singletons.Prelude> :kind! Bar Bar :: * = NewType ('A :$$$ '['B]) }}} ---- If inline `StripNatList` inside `Family` definition: {{{#!hs type family Family (natList :: NatList) = (r :: Type) | r -> natList where Family '[] = () Family xs = NewType (Map SndSym0 xs) }}} or change `StripNatList` definition to type family: {{{#!hs type family StripNatList (natList :: NatList) where StripNatList '[] = '[] StripNatList ('(n, x) ': xs) = x ': StripNatList xs }}} compilation expectedly fails with `Type family equation violates injectivity annotation.` ---- Moreover, if I remove `NewType` from `Family` and change result kind: {{{#!hs type family Family (natList :: NatList) = (r :: [Payload]) | r -> natList where Family xs = StripNatList xs }}} it fails with correct error regardless of `StripNatList` definition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12005: Constraint instances not shown in `:info`
by GHC 14 Oct '18

14 Oct '18

#12005: Constraint instances not shown in `:info` -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci -XKindSignatures -XRank2Types -XConstraintKinds -XAllowAmbiguousTypes -XInstanceSigs GHCi, version 8.1.20160428: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Kind Prelude Data.Kind> class Defer (p :: Constraint) where defer :: (p => r) -> r Prelude Data.Kind> instance Defer () where defer :: r -> r; defer = id Prelude Data.Kind> :i Defer class Defer (p :: Constraint) where defer :: (p => r) -> r {-# MINIMAL defer #-} -- Defined at <interactive>:2:1 }}} Same happens with the [https://github.com/ekmett/constraints/blob/master/src/Data/Constraint/Defer… Data.Constraint.Deferrable] which defines: {{{#!hs instance (Typeable a, Typeable b) => Deferrable (a ~ b) instance (Deferrable a, Deferrable b) => Deferrable (a, b) instance (Deferrable a, Deferrable b, Deferrable c) => Deferrable (a, b, c) }}} but no instances are shown: {{{ ghci> import Data.Constraint.Deferrable ghci> :i Deferrable class Deferrable (p :: Constraint) where deferEither :: proxy p -> (p => r) -> Either String r {-# MINIMAL deferEither #-} -- Defined in ‘Data.Constraint.Deferrable’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12005> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function)
by GHC 13 Oct '18

13 Oct '18

#8763: forM_ [1..N] does not get fused (10 times slower than go function) ------------------------------+-------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Apparently idiomatic code like {{{forM_ [1.._N]}}} does not get fused away. This can give serious performance problems when unnoticed. {{{ -- Slow: forM_ [0.._N-1] $ \i -> do ... -- Around 10 times faster: loop _N $ \i -> do ... {-# INLINE loop #-} loop :: (Monad m) => Int -> (Int -> m ()) -> m () loop bex f = go 0 where go !n | n == bex = return () | otherwise = f n >> go (n+1) }}} Full code example: https://gist.github.com/nh2/8905997 - the relevant alternatives are commented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 86