October 2016 - ghc-tickets

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 24 Oct '16

24 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: 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 simonpj): I think Max was asking for something less fundamental. He just wanted the `deriving` clause on the original instance decl to infer an instance context of `Eq (Associated a)`. That's usually not allowed for `deriving` clauses but he argues that in the context of a class instance decl, it should. So it's just to do with the relatively narrow question of "what context does one infer for a deriving clause?". Since the standalone deriving clause is available, I'm inclined to say "use the standalone route". It's just clearer. But I'm not terribly bothered. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12618: Add saturated constructor applications to Core
by GHC 24 Oct '16

24 Oct '16

#12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- A long-standing performance bug in GHC is its behaviour on nested tuples. * The poster-child case is #5642. * The problem is that when you have a nested tuple application, e.g. `((4,True),('c','d'))`, the size of the type arguments grows quadratically with the expression size. This bites badly in some approaches to generic programming, which use nested tuples heavily. * It's explained in detail in Section 2.3 of [http://research.microsoft.com/en- us/um/people/simonpj/papers/variant-f/index.htm Scrap your type applications]. The same paper describes a solution, a modification of System F called System IF. It's neat, and I did once implement in in GHC. But it was quite complicated; most of the time the win was not big; and I don't know how it'd interact with casts, coercions, and type dependency in the latest version of GHC's Core. So here's another idea, which came up in converstion at ICFP'16: '''add a staturated constructor application to Core'''. So Core looks like {{{ data Expr v = Var v | App (Expr v) (Expr v) ... | ConApp DataCon [Expr v] -- NEW }}} Now I hate the idea of adding a new constructor to Core; I often brag about how few constructors it has. But the idea is this: * A `ConApp` is always saturated; think of it as an uncurried application. * Every data constructor has a wrapper Id. For simple constructors like `(:)`, the wrapper is just a curried version: {{{ (:) = /\a. \(x:a). \(y:[a]). (:) [x,y] }}} where the "`(:) [x,y]`" is just my concrete syntax for a `ConApp` node. * We are used to having an intro and elim form for each type former. So for `(->)` the intro form is `\x.e` and the elim form is `(e1 e2)`. For a data type like `Maybe`, the elim form is `case`, but what's the intro form? `ConApp` of course. * A `ConApp` mentions the `DataCon` explicitly, rather than having it buried inside the `IdDetails` of an `Id`, which somehow seems more honest. The proximate reason for doing this in the first place is to allow us to omit type arguments. Consider `Just True`. Curently we represent this as {{{ Var "Just" `App` Type boolTy `App` Var "True" }}} But with `ConApp` we can say {{{ ConApp "Just" [ConApp "True" []] }}} because it's easy to figure out the `boolTy` type argument from the argument. (We don't really have strings there, but you get the idea.) Can we omit ''all'' the type arguments? No: we can omit only those that appear free in any of the argument types. That is usally all of them (including existentials) but not always. Consider: {{{ data (,) a b where (,):: forall a b. a -> b -> (a,b) data [] a where [] :: forall a. [a] (:) :: forall a. a -> [a] -> [a] data Either a b where Left :: forall a b. a -> Either a b Right :: forall a b. b -> Either a b data (:=:) a b where Refl :: forall a b. (a~b) -> :=: a b data Foo where MkFoo :: a -> (a -> Int) -> Foo }}} For all of these data constructors except `[]` (nil), `Left` and `Right` we can omit all the type arguments, because we can recover them by simple matching against the types of the arguments. A very concrete way to think about this is how to implement {{{ exprType :: Expr Id -> Type exprType (Var v) = varType v exprType (Lam b e) = mkFunTy (varType b) (exprType e) exprType (App f a) = funResultTy (exprType f) ... exprType (ConApp con args) = mkTyConApp (dataConTyCon con) ??? }}} We know that the result type of type of a `ConApp` will be `T t1 ..tn` where `T` is the parent type constructor of the `DataCon`. But what about the (universal) type args `???`? We can get them from the types of the arguments `map exprType args`: * For `ConApp "(:)" [e1, e2]`, the type arument is just `exprType e1`. * For `ConApp "(:=:)" [e]`", we expect `exprType e` to return a type looking like `TyConApp "~" [t1, t2]`. Then `t1` and `t2` are the types we want. So matching is required. * What about an application of `Left`?? We need to recover two type args, but `exprType e1` gives us only one. So we must retain the other one in the application: `ConApp "Left" [Type ty2, e1]`. Similarly for the empty list. A simple once-and-for-all analyis on the `DataCon` will establish how to do the matching, which type args to retain, etc. Tradeoffs: * Pro: We can eliminate almost all type args of almost all data constructors; and for nested tuples we can eliminate all of them. * Pro: it's elegant having the intro/elim duality. * Pro: in GHC we often ask "is this expression a saturated constructor application?" (see `exprIsConApp_maybe`) and `ConApp` makes it easier to answer that question. * Pro: we do exactly this in types: we have `AppTy` and `TyConApp`. (In types a `TyConApp` is not required to be satureted, but we could review that choice.) * Con: adding a constructor is a big deal. In lots of places we'd end up saying {{{ f (App e1 e2) = App (f e1) (f e2) f (ConApp c es) = ConApp c (map f es) }}} In the olden days GHC's `App` had multiple arguments and the continual need to work over the list was a bit tiresome. Still `ConApp` is very simple and uniform; quite often adding `map` won't be difficult; and it may well be that constructors need to be treated differently anyway. * Con: it's not a general solution to the type-argument problem. See #9198 for example. System IF is the only general solution I know, but it seems like too big a sledgehammer. We'll only know if we try it. I estimiate that it would take less than a week to work this change through all of GHC. 90% of it is routine. Other possibly-relevant tickets are #8523, #7428, #9630. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12618> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #12731: Generic type class has type family; leads to big dep_finsts
by GHC 24 Oct '16

24 Oct '16

#12731: Generic type class has type family; leads to big dep_finsts -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to determine a good explanation for simonpj's question in Phab:D2607, I noticed that `dep_finsts` was a lot larger than I would have ordinarily expected it to be: it included many modules that did not have the `TypeFamilies` extension enabled for them. For example, for one module in Cabal, here's "family instance modules": {{{ family instance modules: Distribution.Compat.Semigroup Distribution.Compiler Distribution.ModuleName Distribution.Package Distribution.Simple.Compiler Distribution.System Distribution.Utils.ShortText Distribution.Verbosity Distribution.Version Language.Haskell.Extension Control.Applicative Data.Complex Data.Either Data.Functor.Const Data.Functor.Identity Data.List.NonEmpty Data.Monoid Data.Semigroup Data.Type.Equality Data.Version Data.Void GHC.Exts GHC.Generics GHC.IO.Exception GHC.TypeLits Data.IntMap.Base Data.IntSet.Base Data.Map.Base Data.Sequence Data.Set.Base Text.PrettyPrint.Annotated.HughesPJ Text.PrettyPrint.HughesPJ }}} Do we *really* have this many type family instances in base and Cabal? I was flummoxed, until I realized that the Generic type class defines a type family! {{{ -- | Representable types of kind *. -- This class is derivable in GHC with the DeriveGeneric flag on. class Generic a where -- | Generic representation type type Rep a :: * -> * -- | Convert from the datatype to its representation from :: a -> (Rep a) x -- | Convert from the representation to the datatype to :: (Rep a) x -> a }}} The upshot is that if you derive Generic, you have agreed to a perpetual interface file size tax on every module which transitively depends on your module, as well as lots of fruitless pairwise consistency checking. Ick, especially considering that it's fairly common practice to slap a Generic on every data type you define. This is a case where we would gain a lot if we could put a local restriction on Generic instances so that individual instances are guaranteed not to overlap, e.g., like one of the rules that Rust uses (http://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan- impls/) Then we'd avoid balling up a big transitive closure of all modules that wrote `deriving Generic`. Since non-overlapness is guaranteed by construction, we'd no longer need an eager check. Related #5224 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 24 Oct '16

24 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: I feel like batterseapower is arguing for a change in the way associated family instances work at a fundamental level. To illustrate what I mean, consider this code: {{{#!hs {-# LANGUAGE TypeFamilies #-} class C a where data D a c :: a -> a -> Bool instance Eq a => C [a] where newtype D [a] = DList [a] c = (==) dlist :: D [a] dlist = DList [] }}} Notice that I was able to construct a value of type `D [a]` without needing an `Eq a` constraint! That flies in the face of the fact that the `C [a]` instance does seem to require an `Eq a` constraint—rather, it requires an `Eq a` constraint, but only when typechecking its associated methods. For better or worse, the `D [a]` family instance appears to be pretty much independent of the `C [a]` instance (and its methods). So if we accept batterseapower's proposal above and propagate class constraints down to the associated family instances as well, would it be correct to say that my example code would now fail to typecheck? Is this desirable behavior? I don't really understand the intricacies of associated family instances that well, so perhaps there is a reason that the current design is the way it is. I'd need Simon's judgment to know for sure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4162: GHC API messes up signal handlers
by GHC 24 Oct '16

24 Oct '16

#4162: GHC API messes up signal handlers -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: GHC API | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2633 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * cc: hsyl20 (added) * status: new => patch * differential: => D2633 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4162#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2721: Newtype deriving doesn't work with type families
by GHC 24 Oct '16

24 Oct '16

#2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T2721 Blocked By: | Blocking: Related Tickets: #8165 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * related: => #8165 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2721#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12761: Type aliases for TypeError constrains fire during compilation time
by GHC 24 Oct '16

24 Oct '16

#12761: Type aliases for TypeError constrains fire during compilation time -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello! The following code should compile fine: {{{ module Main where import GHC.TypeLits (ErrorMessage(Text, ShowType, (:<>:)), TypeError) type MyError a b = TypeError (ShowType a :<>: ShowType b) main :: IO () main = return () }}} but it raises an error during compilation: {{{ Main.hs:5:1: error: • ab • In the type synonym declaration for ‘MyError’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7808: data families and TH names do not mix well (e.g. cannot use TH deriving)
by GHC 24 Oct '16

24 Oct '16

#7808: data families and TH names do not mix well (e.g. cannot use TH deriving) -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.2 Resolution: | Keywords: TypeFamilies 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 RyanGlScott): Apologies for commenting on an extremely old Trac ticket. The way I tackle this problem in libraries like `bifunctors` (see [http://hackage.haskell.org/package/bifunctors-5.4.1/docs/Data-Bifunctor- TH.html#v:deriveBifunctor Data.Bifunctor.TH]) is by allowing functions of the form `:: Name -> Q a` to take either a type constructor `Name` (for a plain datatype) or a data constructor `Name` (for a data family instance). The TH code is able to look up the original data family instance from any of its data constructor names, so it works, although it's a bit awkward. There's also the drawback that you can't do this trick for data family instances with no constructors... but how useful are those, really? :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7808#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12760: Assertion failed with BuildFlavour = devel2 (yet another)
by GHC 24 Oct '16

24 Oct '16

#12760: Assertion failed with BuildFlavour = devel2 (yet another) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Still trying to debug compilation failures in our codebase, still can't build prerequisites yet. ghc needs to be compiled with BuildVlavour = devel2 and compilation with -O2 is required: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} module A where import Data.List(minimumBy) import Data.Ord (comparing) data A a = A Int newtype B = B Double deriving (Eq,Ord,Num,Real,Fractional,RealFrac,Floating,RealFloat) class C a where _c :: [a] -> D a instance C B where _c = f2 u data D x = D [(x,Double)] [ x ] u = undefined f1 :: RealFloat a => A a -> a -> [a] -> D a f1 (A a1) m ps0 = D (zip tickvs []) labelvs where range _ | m == m = if m==0 then (-1,1) else (m, m) labelvs = map fromRational $ f3 (fromIntegral a1) (range ps0) tickvs = map fromRational $ f3 (fromIntegral a1) (head labelvs, head labelvs) f2 :: RealFloat a => A a -> [a] -> D a f2 lap ps = f1 u (minimum ps) ps f3 :: RealFloat a => a -> (a,a) -> [Rational] f3 k rs@(m,_ ) = map ((s*) . fromIntegral) [floor m .. ] where s = minimumBy (comparing ((+ k) . realToFrac)) [0] }}} {{{ % ghc -O2 A.hs [1 of 1] Compiling A ( A.hs, A.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1978:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2014:17 in ghc:TyCoRep substTy, called at compiler/types/Coercion.hs:1454:33 in ghc:Coercion in_scope InScope [00 :-> wild_00, X1o :-> wild_X1o, X1p :-> wild_X1p, a4z5 :-> $c==_a4z5, a4zs :-> $c/=_a4zs, a4zV :-> $ccompare_a4zV, a4Ai :-> $c<_a4Ai, a4AF :-> $c<=_a4AF, a4B2 :-> $c>_a4B2, a4Bp :-> $c>=_a4Bp, a4BM :-> $cmax_a4BM, a4C9 :-> $cmin_a4C9, a4Cy :-> $c+_a4Cy, a4CV :-> $c-_a4CV, a4Di :-> $c*_a4Di, a4DF :-> $cnegate_a4DF, a4DY :-> $cabs_a4DY, a4Eh :-> $csignum_a4Eh, a4EA :-> $cfromInteger_a4EA, a4F3 :-> $ctoRational_a4F3, a4Fs :-> $c/_a4Fs, a4FP :-> $crecip_a4FP, a4G8 :-> $cfromRational_a4G8, a4GB :-> $cproperFraction_a4GB, a4Hg :-> $ctruncate_a4Hg, a4HV :-> $cround_a4HV, a4IA :-> $cceiling_a4IA, a4Jf :-> $cfloor_a4Jf, a4K0 :-> $cpi_a4K0, a4Kf :-> $cexp_a4Kf, a4Ky :-> $clog_a4Ky, a4KR :-> $csqrt_a4KR, a4La :-> $c**_a4La, a4Lx :-> $clogBase_a4Lx, a4LU :-> $csin_a4LU, a4Md :-> $ccos_a4Md, a4Mw :-> $ctan_a4Mw, a4MP :-> $casin_a4MP, a4N8 :-> $cacos_a4N8, a4Nr :-> $catan_a4Nr, a4NK :-> $csinh_a4NK, a4O3 :-> $ccosh_a4O3, a4Om :-> $ctanh_a4Om, a4OF :-> $casinh_a4OF, a4OY :-> $cacosh_a4OY, a4Ph :-> $catanh_a4Ph, a4PA :-> $clog1p_a4PA, a4PT :-> $cexpm1_a4PT, a4Qc :-> $clog1pexp_a4Qc, a4Qv :-> $clog1mexp_a4Qv, a4QY :-> $cfloatRadix_a4QY, a4Rh :-> $cfloatDigits_a4Rh, a4RA :-> $cfloatRange_a4RA, a4RT :-> $cdecodeFloat_a4RT, a4Sc :-> $cencodeFloat_a4Sc, a4Sz :-> $cexponent_a4Sz, a4SS :-> $csignificand_a4SS, a4Tb :-> $cscaleFloat_a4Tb, a4Ty :-> $cisNaN_a4Ty, a4TR :-> $cisInfinite_a4TR, a4Ua :-> $cisDenormalized_a4Ua, a4Ut :-> $cisNegativeZero_a4Ut, a4UM :-> $cisIEEE_a4UM, a4V5 :-> $catan2_a4V5, a4Vu :-> $c_c_a4Vu, a5eH :-> wild_a5eH, a5eJ :-> x_a5eJ, ruN :-> u, ruO :-> f1, ruP :-> f2, ruQ :-> f3, r24E :-> $tc'A, r25L :-> $tcA, r25N :-> $tc'B, r25Z :-> $tcB, r2dl :-> $tc'D, r2ds :-> $tcD, r2dF :-> $tcC, r2dG :-> $tc'C:C, r2dL :-> $fCB, r2dZ :-> $fEqB, r2ec :-> $fOrdB, r2nC :-> $fNumB, r2nK :-> $fRealB, r2nT :-> $fFractionalB, r2oa :-> $fRealFracB, r2oC :-> $fFloatingB, r2oX :-> $fRealFloatB, r4yJ :-> $trModule, s5iM :-> $trModule_s5iM, s5iN :-> $trModule_s5iN, s5iO :-> $tc'A_s5iO, s5iQ :-> $tc'B_s5iQ, s5iR :-> $tcB_s5iR, s5iS :-> $tc'D_s5iS, s5iT :-> $tcD_s5iT, s5iU :-> $tc'C:C_s5iU, s5iV :-> $tcC_s5iV, s5jw :-> $sf2_s5jw, s5jM :-> $sf1_s5jM, s5jU :-> labelvs_s5jU, s5k8 :-> $sf3_s5k8, s5ki :-> $sfromIntegral_s5ki, s5kD :-> $sminimum_s5kD, s5kE :-> $scomparing_s5kE, s5kF :-> $srealToFrac_s5kF, s5kG :-> $sfromIntegral_s5kG, s5kN :-> lvl_s5kN, s5kX :-> lvl_s5kX, s5lc :-> lvl_s5lc, s5ln :-> lvl_s5ln, s5pu :-> lvl_s5pu, s5pv :-> lvl_s5pv, s5ra :-> lvl_s5ra, s5rb :-> lvl_s5rb, s5Bi :-> $w$sf3_s5Bi, s5Bt :-> $wf3_s5Bt, s5Bx :-> w_s5Bx, s5BB :-> ww_s5BB, s5BF :-> $w$sf1_s5BF, s5BS :-> $wf1_s5BS, s5BW :-> $wf2_s5BW, s5D0 :-> $j_s5D0, s5FJ :-> lvl_s5FJ, s5FL :-> $wgo_s5FL, s5FM :-> lvl_s5FM, s5FN :-> lvl_s5FN, s5FP :-> karg_s5FP, s5FW :-> go_s5FW, s5FX :-> lvl_s5FX, s5FY :-> lvl_s5FY, s5FZ :-> lvl_s5FZ, s5G0 :-> lvl_s5G0, s5G1 :-> lvl_s5G1, s5G2 :-> lvl_s5G2, s5G4 :-> lvl_s5G4, s5G5 :-> lvl_s5G5, s5G6 :-> lvl_s5G6, s5G7 :-> lvl_s5G7, s5Io :-> $s$j_s5Io, s5Ip :-> $s$j_s5Ip, s5Ir :-> $sgo_s5Ir] tenv [] tenvFVs [] cenv [s5Ij :-> sg_s5Ij, s5Ik :-> sg_s5Ik] cenvFVs [s5Ij :-> sg_s5Ij, s5Ik :-> sg_s5Ik] tys [Ratio Integer] cos [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12427: Type inference regression with RankNTypes (GHC 8.1)
by GHC 24 Oct '16

24 Oct '16

#12427: Type inference regression with RankNTypes (GHC 8.1) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: RankNTypes | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following module compiles fine with ghc-8.0.1: {{{#!hs {-# LANGUAGE RankNTypes #-} module Acquire where newtype Acquire a = Acquire {unAcquire :: (forall b. b -> b) -> IO a} instance Functor Acquire where fmap = undefined instance Applicative Acquire where pure = undefined (<*>) = undefined instance Monad Acquire where Acquire f >>= g' = Acquire $ \restore -> do x <- f restore let Acquire g = g' x -- let g = unAcquire (g' x) g restore }}} HEAD (83e4f49577665278fe08fbaafe2239553f3c448e, ghc-8.1.20160720) reports: {{{ Acquire.hs:17:21: error: • Couldn't match expected type ‘t’ with actual type ‘(forall b1. b1 -> b1) -> IO b’ ‘t’ is a rigid type variable bound by the inferred type of g :: t at Acquire.hs:17:13-28 • In the pattern: Acquire g In a pattern binding: Acquire g = g' x In the expression: do { x <- f restore; let Acquire g = g' x; g restore } • Relevant bindings include g' :: a -> Acquire b (bound at Acquire.hs:15:19) (>>=) :: Acquire a -> (a -> Acquire b) -> Acquire b (bound at Acquire.hs:15:15) }}} This example is reduced from the `recourcet` package on Hackage, module `Data.Acquire.Internal`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7