[GHC] #12670: Representation polymorphism validity check is too strict
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As of 465c6c5d15f8fb54afb78408f3a79e75e74d2cd4 GHC rejects this program, {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE RankNTypes #-} module Hi where import GHC.Exts data TypeRep (a :: k) where TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) }}} Claiming that it has inappropriate polymorphism over `RuntimeRep`, {{{ $ ghc hi2.hs [1 of 1] Compiling Hi ( hi2.hs, hi2.o ) hi2.hs:7:5: error: • A representation-polymorphic type is not allowed here: Type: a Kind: TYPE r1 • In the definition of data constructor ‘TrFun’ In the data type declaration for ‘TypeRep’ }}} I suspect this check is unnecessarily strict since we never need to store a value of type `a` to represent `TypeRep a` at runtime. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 goldfire): Yes, I suppose `checkForRepresentationPolymorphism` is a bit loose in its definition of what is representation polymorphic. It should look for the kind to be `TYPE blah` before proceeding. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 bgamari): Well, I'm not quite sure that is sufficient; afterall the kind of `a` in the above example indeed has the form `TYPE blah`. Rather, it seems like we need some way of determining whether a particular `RuntimeRep` variable affects the runtime representation of a type. It would seem at first glance that given a function type, e.g. `a -> b`, we would want to check that the kinds of `a` and `b` both have no free `RuntimeRep` variables. I suspect this is the only check necessary. We can assume that applications of any other tycon to `RuntimeRep` variables is safe since the type has already been subject to the `checkForRepresentationPolymorphism` check. Consequently, we have already determined that none of the type's type arguments will affect its representation and therefore any well-kinded application is safe. Therefore, I propose that `checkForRepresentationPolymorphism` is simply the following, {{{#!hs checkForRepresentationPolymorphism :: SDoc -> Type -> TcM () checkForRepresentationPolymorphism extra ty | Just (tc, tys) <- splitTyConApp_maybe ty , isUnboxedTupleTyCon tc || isUnboxedSumTyCon tc = mapM_ (checkForRepresentationPolymorphism extra) (dropRuntimeRepArgs tys) | tuple_rep || sum_rep = {- fail -} | (args, res) <- splitFunTys ty , not $ all is_safe_arrow_argument (res:args) = {- fail -} | otherwise = return () where tuple_rep = runtime_rep `eqType` unboxedTupleRepDataConTy sum_rep = runtime_rep `eqType` unboxedSumRepDataConTy tuple_or_sum = text (if tuple_rep then "tuple" else "sum") ki = typeKind ty runtime_rep = getRuntimeRepFromKind "check_type" ki is_safe_arrow_argument = isEmptyVarSet . tyCoVarsOfType . getRuntimeRepFromKind "check_type" . typeKind }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 8.2.1
Component: Compiler (Type | Version: 8.0.1
checker) |
Resolution: | Keywords: typeable
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 bgamari):
It seems that the above validity check loosening would also require that
the Core Linter be loosened a bit. Otherwise, we find that this program
will typecheck yet then fail due to validity check errors,
{{{#!hs{-# LANGUAGE TypeInType, PolyKinds, GADTs, RankNTypes #-}
module Hi where
import GHC.Exts
data Fingerprint = Fingerprint
data TyCon = TyCon
data TypeRep (a :: k) where
TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
(a :: TYPE r1) (b :: TYPE r2).
Fingerprint
-> TypeRep a
-> TypeRep b
-> TypeRep (a -> b)
data AppResult (t :: k) where
App :: TypeRep a -> TypeRep b -> AppResult (a b)
splitApp :: TypeRep a -> Maybe (AppResult a)
splitApp (TrFun _ _ _) = Nothing
}}}
The Core lint issues stem from the fact that we have number of (unused)
coercion bindings in scope in the produced Core whose types fail the
`okArrowArgKind` check performed by `lintArrow`. For instance,
{{{#!hs
splitApp :: forall k_a2Xm (a_a2VN :: k_a2Xm).
TypeRep k_a2Xm a_a2VN -> Maybe (AppResult k_a2Xm a_a2VN)
splitApp =
\ (@ k_a2Xu)
(@ (a_a2Xv :: k_a2Xu))
(ds_d37A :: TypeRep k_a2Xu a_a2Xv) ->
case ds_d37A of wild_00
{ TrFun @ r1_a2Xx @ r2_a2Xy @ a_a2Xz @ b_a2XA
cobox_a2XB cobox_a2XC
ds_d37Y ds_d37Z ds_d380 ->
...
let {
cobox_a2XU :: ((a_a2Xv |> cobox_a2XB) :: *) ~# ((a_a2Xz ->
b_a2XA) :: *)
cobox_a2XU = CO:
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 my fix to #12668 may have fixed comment:3. Not certain. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 bgamari): Simonpj, which fix is this? I haven't seen a fix for #12668 yet; presumably it has yet to be merged? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 I failed to push; will do tomorrow -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 bgamari): The patch that Simon was referring to in comment:4 was eefe86d96d40697707c3ddfb9973a30a1897241f. Unfortunately this doesn't fix the issue which described by this ticket; the typechecker still rejects the program given in the ticket description. Richard and I discussed this a few weeks ago and came to a solution which looks something like this, {{{#!patch diff --git a/compiler/typecheck/TcPatSyn.hs b/compiler/typecheck/TcPatSyn.hs index 5c62121..62724c8 100644 --- a/compiler/typecheck/TcPatSyn.hs +++ b/compiler/typecheck/TcPatSyn.hs @@ -13,6 +13,7 @@ module TcPatSyn ( tcInferPatSynDecl, tcCheckPatSynDecl ) where import HsSyn +import TcHsSyn( checkForRepresentationPolymorphism ) import TcPat import Type( mkTyVarBinders, mkEmptyTCvSubst , tidyTyVarBinders, tidyTypes, tidyType ) @@ -312,6 +313,9 @@ tc_patsyn_finish lname dir is_infix lpat' arg_tys = tidyTypes env2 arg_tys' pat_ty = tidyType env2 pat_ty' + -- Check that the arguments aren't representationally polymorphic + ; mapM_ (checkForRepresentationPolymorphism empty) arg_tys + ; traceTc "tc_patsyn_finish {" $ ppr (unLoc lname) $$ ppr (unLoc lpat') $$ ppr (univ_tvs, req_theta, req_ev_binds, req_dicts) $$ diff --git a/compiler/typecheck/TcTyClsDecls.hs b/compiler/typecheck/TcTyClsDecls.hs index c009bc9..9335676 100644 --- a/compiler/typecheck/TcTyClsDecls.hs +++ b/compiler/typecheck/TcTyClsDecls.hs @@ -2296,6 +2296,9 @@ checkValidDataCon dflags existential_ok tc con -- Check all argument types for validity ; checkValidType ctxt (dataConUserType con) + -- Check for representationally polymorphic fields + ; mapM_ (checkForRepresentationPolymorphism empty) (dataConOrigArgTys con) + -- Extra checks for newtype data constructors ; when (isNewTyCon tc) (checkNewDataCon con) diff --git a/compiler/typecheck/TcValidity.hs b/compiler/typecheck/TcValidity.hs index 6cc40a5..c9f3bda 100644 --- a/compiler/typecheck/TcValidity.hs +++ b/compiler/typecheck/TcValidity.hs @@ -487,8 +487,6 @@ check_type _ _ _ (TyVarTy _) = return () check_type env ctxt rank (FunTy arg_ty res_ty) = do { check_type env ctxt arg_rank arg_ty - ; when (representationPolymorphismForbidden ctxt) $ - checkForRepresentationPolymorphism empty arg_ty ; check_type env ctxt res_rank res_ty } where (arg_rank, res_rank) = funArgResRank rank }}} Unfortunately this still doesn't fix the Core Lint issues that inevitably pop up when you try to use such a type. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 our new paper [https://www.microsoft.com/en- us/research/publication/levity-polymorphism/ Levity polymorphism] shows how to fix this. Richard is working on the implementation. Are you stuck on this? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 goldfire): The fix for this is in branch `wip/T12819`. But I haven't had time to tie the patch up with a bow on top (put tests in, re-validate, etc). Soon. Soon. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 bgamari):
Are you stuck on this?
To an extent, yes I was. The problem is that I cannot really use the `TRFun` that we introduced if I define it as, {{{#!hs data TypeRep (a :: k) where TRFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). TypeRep arg -> TypeRep res -> TypeRep (arg -> res) ... }}} due to the overly strict representational polymorphism checks described in this ticket. I thought would workaround would be to even further narrow the types represented by `TypeRep`. Namely, we only represent arrow types where both `arg` and `res` are of kind `Type`, {{{#!hs data TypeRep (a :: k) where TRFun :: forall arg res. TypeRep arg -> TypeRep res -> TypeRep (arg -> res) ... }}} However, this leads to trouble when implementing serialization, {{{#!hs putTypeRep :: TypeRep a -> Put putTypeRep (TRCon a b c) = putWord8 0 >> ... putTypeRep (TRApp a b c) = putWord8 1 >> ... putTypeRep (TRFun arg res) = putWord8 2 >> putTypeRep arg >> putTypeRep res ... getSomeTypeRep :: Get SomeTypeRep getSomeTypeRep = do tag <- getWord8 case tag of 0 -> ... 1 -> ... 2 -> do arg <- getSomeTypeRep res <- getSomeTypeRep {- uh oh! We don't know the kinds of arg and res -} return (TRFun arg res) }}} The trouble here is that, since we have dropped `typeRepKind`, we have no way of verifying during deserialization that `arg` and `res` indeed have kind `Type`. However, it sounds like `wip/T12819` should unstick me; if I'm not mistaken none of this should be problematic assuming we are able to represent arrows with arbitrary argument and result kinds. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 bgamari): It turns out that the lack of `typeRepKind` has one more unfortunate effect: `Data.Dynamic.dynApply` can no longer be safely implemented. The reason is that we have no means of verifying that the result type of the function being applied is of kind `Type`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 bgamari): To put a finer point on the concern I raised in comment:11: Consider this example, {{{#!hs data TypeRep (a :: k) pattern Fun :: forall k k' (a :: k) (b :: k'). a -> b -> TypeRep (a -> b) -- As seen in "A reflection on types" data Dynamic where Dyn :: TypeRep a -> a -> Dynamic dynApply :: Dynamic -> Dynamic -> Maybe Dynamic dynApply (Dyn rf f) (Dyn rx x) = do Fun arg res <- pure rx Just HRefl <- eqTypeRep arg rx -- We now know that the argument types match up but what about the -- result type? -- -- In order to package up the result (f x) into a `Dyn` we must -- know that the its type is of kind *. However, we don't know -- this since TypeRep's index is poly-kinded. -- -- Consequently we really need to do this, which requires typeRepKind, Just HRefl <- eqTypeRep (typeRepKind res) (typeRep @Type) pure $ Dyn res (f x) -- Consider this example... f :: Int -> Int# f (I# n#) = n# df :: Dynamic df = Dyn f -- Here is an example of a use of Dynamic that would expose the issue in dynApply uhOh :: Maybe Dynamic uhOh = dynApply df (Dynamic (42::Int)) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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): Very good point. We can't make `Dyn res (f x)` unless `f x :: Type`, I agree. Let's see what Richard has to say. What is `Fun`? You're referring to some code I can't see. In any case, I'd remark that we don't necessarily need the full generality of `typeRepKind`; we only need to know the arguments to `(->)` when we take `rx` apart. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 goldfire): Replying to [comment:13 simonpj]:
Let's see what Richard has to say.
I say "yes". I also say that your `Fun` is quite wrong. I prefer this one: {{{#!hs pattern Fun :: forall k (a_to_b :: k). () => forall r r' (a :: TYPE r) (b :: TYPE r'). (k ~ Type, a_to_b ~ (a -> b)) => TypeRep a -> TypeRep b -> TypeRep a_to_b }}} But otherwise I agree with your conclusions. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 bgamari):
I also say that your Fun is quite wrong. I prefer this one:
That is true and I implement your variant in the branch; I probably should have written `Fun` as a GADT-style constructor of `TypeRep` to avoid confusion. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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): But do we need the full glory of `typeRepKind`, or just the ability to look at `(->)` levity arguments? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: typeable, Resolution: | LevityPolymorphism 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 simonpj): * keywords: typeable => typeable, LevityPolymorphism -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: typeable, Resolution: | LevityPolymorphism 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 bgamari): @simonpj, I believe we need `typeRepKind`. However, I'm well on my way to implementing it. Unfortunately I'm somewhat blocked on #12905. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: typeable, Resolution: | LevityPolymorphism 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 bgamari): * priority: normal => high * owner: => goldfire Comment: Richard should be taking care of this as part of the levity polymorphism work. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: typeable, Resolution: fixed | LevityPolymorphism 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 bgamari): * status: new => closed * resolution: => fixed Comment: This is now fixed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Typeable, Resolution: fixed | LevityPolymorphism 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 simonpj): * keywords: typeable, LevityPolymorphism => Typeable, LevityPolymorphism -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12670#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC