#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dreixel): * owner: => dreixel -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e): This bug means that lambdabot cannot enable {{{DataKinds}}} (see #10000 for how to implement {{{unsafeCoerce}}} using this.) I would really like to see this fixed in 7.10.1. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by int-e): * cc: int-e (added) * priority: normal => high * milestone: 7.12.1 => 7.10.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Pedro when do you think you might get to this? Thanks See also #10000 Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

Replying to [comment:7 dreixel]:

...

Replying to [comment:5 int-e]:

...

One way of fixing this would be to prepend a prime (or some other non-capital letter character) to {{{name_fs}}} in {{{TcGenDeriv.gen_Typeable_binds}}} if the given {{{tycon::TyCon}}} is a

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dreixel): Replying to [comment:9 oerjan]: promoted data constructur.

...

...

Is this sufficient (...)

I believe so. It should be a really simple fix.

Nope, here is a version based simply on using different promoted kinds (that are not visible in the Typeable instance). Also works to modify Shachaf's unsafeCoerce from #10000.

{{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE AutoDeriveTypeable #-}

import Data.Typeable

data A t = A

main = print $ typeRep (Proxy :: Proxy (A :: Bool -> *)) == typeRep (Proxy :: Proxy (A :: Ordering -> *))

}}}

I think this example highlights a different limitation of Typeable, along the lines of #7897. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Pedro: how do you suggest we proceed with this? It seems quite urgent if you can use it to write `unsafeCoerce`. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:14 simonpj]:

Pedro: how do you suggest we proceed with this? It seems quite urgent if you can use it to write `unsafeCoerce`.

Simon

If I may comment too, I think the ''long-term'' solution for these bugs cannot be anything less than including kind information in typereps, at least for type constructors of polymorphic kind. However that may be too hard to get done in the short term, in which case one possibility might be to somehow disallow `PolyKinds`, or possibly `Typeable` instances for polykinds, in Safe Haskell. Note that exploiting this doesn't require any explicit extensions mentioning kinds, `Typeable` or deriving, this was my last version (works in GHCi 7.8.3): {{{ {-# LANGUAGE TypeFamilies #-} import Data.Typeable type E = (:~:) data family F p a b newtype instance F a b (Proxy (Proxy :: * -> *)) = ID (a -> a) newtype instance F a b (Proxy (Proxy :: (* -> *) -> *)) = UC (a -> b) -- Needed to prevent faulty inlining in GHCi. Maybe expand further if it -- breaks at higher optimization levels. munge = id ecast :: E p q -> f p -> f q ecast Refl = id supercast :: F a b (Proxy (Proxy :: * -> *)) -> F a b (Proxy (Proxy :: (* -> *) -> *)) supercast = case cast e of Just e' -> munge ecast e' where e = Refl e :: E (Proxy (Proxy :: * -> *)) (Proxy (Proxy :: * -> *)) uc :: a -> b uc = case supercast (ID id) of UC f -> f }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dreixel): Here's the current definition of `TypeRep`: {{{ data TypeRep = TypeRep {-# UNPACK #-} !Fingerprint TyCon [TypeRep] data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, tyConPackage :: String, tyConModule :: String, tyConName :: String } }}} Could we perhaps add a `tyConKind :: TypeRep` to `TyCon`, and make sure that it is used when computing the hash? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Richard is spot on. For (1), really `A` and `'A` are entirely different, and should not compare as equal. That is probably easy to fix, by changing the fingerprint we generate for `'A`. For (2), yes absolultely, just as `Maybe Int` and `Maybe Bool` should have non-equal `TypeRep`s, so should `B 'Ordering` and `B 'Bool`. The fact that is's a kind application isn't important. The ''reason'' that bug (2) happens is, I think, that the `Typeable` instance of `B` is generated by an instance declaration: {{{ instance Typeable B where typeRep# _ = ...the TyCon for B.... }}} This instance declaration is treated as ''source code'', and source code does implicit kind instantiation. So we actually get {{{ dfun :: forall k. Typeable (B k) dfun = /\k. MkTypeableDict (...TyCon for B....) }}} We don't want this! Instead we want to treat `(B 'Bool)` just like `Maybe Bool`, using the application instance (in `Data.Typeable.Internals`), which looks roughly like this: {{{ instance (Typeable s, Typeable a) => Typeable (s a) where -- See Note [The apparent incoherence of Typable] typeRep# _ = typeRep a `mkAppTy` typeRep b }}} We would like this to be done for ''kind'' applications as well as ''type'' applications. So we need two changes * For type constructors, we need an instance that truly matches on `B` not on `B k` * We need to decompose kind applications as we do type applications. To me it seems clear that we should move to treating `Typeable` more like we treat `Coercible`, i.e. as a built-in type class that the constraint solver knows how to solve, rather than as something handed with source- level instance declarations. That would imply: * There would be no `Typeable` instances in the instance environment (which itself would be a modest saving). * Either 1. every data type constructor automatically has a `Typeable` instance (which I favour), or 1. we'd need a tiresome separate mechanism (a flag in the `TyCon`) to say whether it does or does not have a `Typeable` instance. Note that this path might ultimately allow us to have a `TypeRep` for a polymorphic type, which we can't do right now. What do people feel about (1) vs (2)? Why would we ever want a type ''not'' to be `Typeable`? Note that the code-size overhead is modest: a single top-level definition of a record defining the `TyCon`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

I will point out one drawback: I believe users will be confused about

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): Replying to [comment:21 goldfire]: the need for `Typeable` constraints. After all, if ''every'' type is `Typeable`, then why include the constraint? We cognoscenti know that the `Typeable` constraint is just implicitly passing the runtime witness, but we'll have to be careful to explain this to those who think that class constraints are all about logical statements, not implicit type-determined parameters. After using Haskell for several years, that ''still'' trips me up. If you are able to make everything `Typeable`, might there be a way to make the `Typeable` constraint implicit, at least when it's needed? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Folks, we need an interim solution for 7.10. A full fix sounds as if it'll take a little longer. But I'm anxious about releasing 7.10 with the ability to write `unsafeCoerce` in Safe Haskell. One drastic remedy: do not derive `Typeable` for polykinded type constructors. That would be easy to implement, and would certainly fix it. But it's a bit drastic. Any other offers? We need to do this in the next two weeks. Better still would be to fix it properly of course. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:25 dreixel]:

How about just marking `Typeable` instances for polykinded type constructors as Unsafe (if that's possible)?

Given how notoriously hard it is to control exports of instances, that won't be enough. To make things worse, the offending instance used here (for {{{Proxy}}}) is derived in {{{Data.Typeable.Internal}}}, which is marked {{{Trustworthy}}}. So conscientious users of safe Haskell would not be able to trust the base package anymore, rendering safe Haskell all but useless. I guess the right way to leverage safe Haskell is to mark {{{Data.Typeable}}} as unsafe, and explain the situation in a big comment. It would still be a pain to track uses of {{{Data.Typeable}}} in {{{Trustworthy}}} modules of other libraries (say, lens and its dependencies). I'm afraid there is no good interim solution here. I favor spj's suggestion, but #9111 suggests that some people actually use {{{Typeable}}} for {{{Proxy}}}. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:27 crockeea]:

To echo @dreixel: What exactly *is* SPJ's suggestion? Is it to not *automatically* derive `Typeable` instances for poly-kinded type constructors, or is to disallow standalone-derived instances as well?

Presumably it would be safe to allow a *single* standalone derivation in the same module that defines the type, as long as it's of actual monomorphic kind. That way, at least `Proxy` could still have a `* -> *` instance, which might be the one that is used the most in practice? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, SPJ's drastic suggestion is: you polykinded type constructor cannot be an instance of `Typeable`, by `deriving`, or `AutoDeriveTypable`, or standalone deriving. Period. Here's an alternative proposal. * `....deriving( Typeable )` (and `AutoDeriveTypeable`) on a polykinded tycon will fail (with a helpful message) * But instead you can give any number of mono-kinded standalone instances {{{ deriving instance Typeable (Proxy :: (* -> *) -> *) }}} Comments on the proposal * It's still not ideal because you can never declare "enough" instances and if you declare an extra one at some use site, it might conflict with someone else's. * It requires some modification to GHC, which current rejects such standalone deriving instances, precisely because they are not fully polymorphic. * And the kinds would have to be included in the fingerprint of the `TyCon` generated by the standalone derived instance. But that seems ok as a holding position. The "right" solution is, I think, at the bottom of comment:20. But NB that solution will mean that all these standalone derived instances would become illegal, so there is a backward compatibility cost. The drastic solution does not have this problem. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:30 simonpj]:

* And the kinds would have to be included in the fingerprint of the `TyCon` generated by the standalone derived instance.

The "right" solution is, I think, at the bottom of comment:20. But NB

Once you have the mechanism for getting a kind representation to put in the fingerprint, how much harder is it to just make it work polymorphically while you're at it? I'm not a GHC developer by any means, but I still had the hunch that this could be a main stumbling block to getting the proper solution working. that solution will mean that all these standalone derived instances would become illegal, so there is a backward compatibility cost. The drastic solution does not have this problem. If *all* types later become `Typeable` automatically, then wouldn't it be safe and backward compatible to just ignore the explicit instances with a redundancy warning? (I've occasionally been thinking that multiple derived instances for the same type and class should often be safely compatible with each other. If made by the same mechanism, they're guaranteed to have the same code, after all. Although I guess standalone deriving with explicit restricted type signature could complicate that.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:33 oerjan]:

But anyway, here it is, sort of working, but with some obvious drawbacks:

One such drawback is that the `Kindable'` constraint is sort of infectious. One can using a type family for mapping kinds to types, which seems to overcome that particular shortcoming: {{{ type family KindRep (p :: k) data Star deriving Typeable type instance KindRep (Proxy :: * -> *) = Star type instance KindRep (Proxy :: (k -> k') -> *) = KindRep (Proxy :: k -> *) -> KindRep (Proxy :: k' -> *) -- some data kinds: () and [] type instance KindRep (Proxy :: () -> *) = () type instance KindRep (Proxy :: [k] -> *) = [KindRep (Proxy :: k -> *)] }}} One could then have {{{ instance Typeable (KindRep (Proxy :: k -> *)) => Typeable' (Proxy :: k -> *) }}} Here's some working code: http://lpaste.net/4263409010180358144 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:34 int-e]:

One such drawback is that the `Kindable'` constraint is sort of infectious. One can using a type family for mapping kinds to types, which seems to overcome that particular shortcoming:

This is already better, but also: Wouldn't this type family become redundant if we had Richard's identification of types and kinds? Assuming this also means you can have classes with only kind parameters, you could possibly get rid of the need for all the `Proxy`s and `UndecidableInstances` as well? At which point this starts to seem a lot prettier. Since I didn't give much comments in my previous version, the main ideas were: 1. Including the kind of a type in its `TTypeRep` already at construction may not have the typing problems that the wiki page describes for a "polymorphic typerep" with separately applied kindrep arguments. 2. You can construct representations for kinds already in current GHC code, although there's boilerplate because you cannot use kinds as "naked" parameters. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:26 int-e]:

I'm afraid there is no good interim solution here. I favor spj's suggestion, but #9111 suggests that some people actually use {{{Typeable}}} for {{{Proxy}}}.

I've changed my mind about SPJ's idea. It's very late in the ghc-7.10 release cycle, and the design of the long-term solution is still in flux, so any ''drastic'' stop-gap measure bears a significant risk of breaking users' code twice. And there are quite a lot of users, not least because `Typeable` is poly-kinded (see also Edward's comment:37 which carries some weight). I'd rather see this bug documented and communicated prominently so that everybody who runs untrusted Haskell code knows about it, and take further measures to sandbox that code. (This is a good idea anyway; ghc, its RTS and the libraries are really too big to be trusted even with `SafeHaskell` enabled.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Take a look at [wiki:Typeable#Medium-termsolution this wiki page]. It includes a solution that we think can be done in time for 7.10 if there is a delay. What's nice about this one is that it should break no existing code. Depending on design decisions, we would probably warn about `Typeable` instances (which would no longer be necessary), but nothing should outright break. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:42 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by liyang): * cc: liyang (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:44 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Ah, I had misunderstood what the wiki page said, then. Now this gives me an idea for a expanded test case. If my picture of how such a solver would work is now more correct, then I think by expanding the kinds in my example a bit, we can get a case where the solver would need not just to ''build'' new kind reps, but also to take the kind rep inside its provided `Typeable` instance further apart. And for good measure let's include a data kind as well: {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable newtype C a b = C () step :: Proxy (a :: [k] -> *) -> Proxy (C a :: [k -> *] -> *) step Proxy = Proxy nest :: Typeable (a :: [k] -> *) => Int -> Proxy a -> TypeRep nest 0 x = typeRep x nest n x = nest (n-1) (step x) main = print $ nest 10 (Proxy :: Proxy (C () :: [()] -> *)) }}} Assuming you would want to support this kind of code. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:46 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): I was going to say that this need to do kind decomposition when inferring `Typeable` instances is why this cannot be done just with standalone instances, and you need a solver. In fact the last time I gave up on my [comment:33 attempt] to express this in source code, it was because I realized that the fundamental instance {{{ instance (Typeable a, Typeable b) => Typeable (a b) }}} already needs such decomposition to be written. But today I had an epiphany: This ''can'' be expressed with current types, although with the annoying need to wrap kinds in proxies: {{{ -- Ideally k itself should be the class argument, but that is not yet -- supported. I think this is what makes UndecidableInstances -- necessary for defining instances. Fortunately the instances seem to be -- usable without it. class (KindableParts a, a ~ Proxy) => Kindable (a :: k -> *) where type KindableParts a :: Constraint kindRep :: KindRep a class Kindable (Proxy :: k -> *) => Typeable (a :: k) where typeRep :: proxy a -> TypeRep }}} I wrote up enough of a mock implementation to make the last test case above work with this. The code is a bit long, so I put it [http://oerjan.nvg.org/haskell/TypeableDesign/ on my website]. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:48 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:49 int-e]:

{{{ f = \(p :: Proxy Proxy) -> typeRep p }}}

Note that currently, the function has type `Proxy Proxy -> Typeable`. What will the type be under the proposed medium term solution? If we want full backward compatibility (and I personally don't think we should strive for that for examples like this one) then passing hidden extra evidence is the only way to go. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:50 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e):

{{{ f :: Typeable (Proxy :: k -> *) => Proxy (Proxy :: k -> *) -> TypeRep }}}

Looks fine to me. Am I missing something?

I'm happy with this type, it's very reasonable, and reflects the fact that some evidence (for `Typeable`) has to be provided by the caller. My main point was that this change will not be 100% backwards compatible (note that the new inferred type for `f` is different from what ghc 7.10 RC2 infers.) I was also slightly afraid that you might want to fudge things (by omitting the extra evidence from Haskell-level type signatures) to make the medium term solution fully backward compatible, but apparently that fear was unjustified. The open question is whether this incompatibility will affect existing real world code. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:52 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e): Here is another testcase, geared towards motivating kind-level `Typeable` evidence (also known as `Kindable`): {{{ f :: Proxy (a :: k) -> Proxy (b :: k) -> Proxy (Proxy :: k -> *) f _ _ = Proxy g pa pb = typeRep (f pa pb) }}} If we allow kind-level `Typeable` constraints, i.e., `Typeable (k :: BOX)`, we would have {{{ g :: Typeable k => Proxy (a :: k) -> Proxy (b :: k) -> TypeRep }}} With just the type-level `Typeable`, we can choose between two constraints, {{{ g :: Typeable (Proxy (a :: k)) => Proxy (a :: k) -> Proxy (b :: k) -> TypeRep g :: Typeable (Proxy (b :: k)) => Proxy (a :: k) -> Proxy (b :: k) -> TypeRep }}} so which one should type inference prefer? Or would `g` require a type signature? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:54 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

{{{ g :: Typeable (Proxy :: (k -> *) -> *) => Proxy (a :: k) -> Proxy (b :: k) -> TypeRep }}}

Again, I don't see the ambiguity, and I think GHC would be able to infer

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:55 goldfire]: this type without trouble... I don't see how this is a special case, really. You're right, it isn't. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:56 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): This defaulting to `*` is precisely what happens without `PolyKinds` on. So anyone not worried about kind variables won't need to. But I don't like this defaulting behavior if `PolyKinds` ''is'' on. If a user has specified `PolyKinds` and writes the code in comment:57, I would want an error to be reported. The choice of the kind variable here is potentially relevant to the programmer's desired behavior, and I think silently guessing a value is wrong here. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:58 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I think your plan (of more defaulting to `*`) would break less code, but I think that someone saying `Proxy Proxy` without thinking about kinds yet specifying `PolyKinds` has made a mistake. After all, the goal is to make the `TypeRep` for `Proxy :: * -> *` and `Proxy :: Bool -> *` different. We should expect the user to specify which one they want. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:60 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: merge Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:62 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: dreixel => * status: merge => new Comment: (Reopening for discussion) Sorry for getting here a bit late; but I have some concerns about this change as it stands currently. Abstractly my main concern is that we've made a change (implicitly deriving Typeable everywhere) for the wrong reasons, and concretely my main fear, given the timing of this change, is that we'll find the new approach is untenable for some reason or other and be forced back into a world in which explicit deriving Typeable is required. I'm certainly not trying to say that implicitly deriving Typeable is the wrong decision; but it seems that it arose as fallout from the issue in this ticket and #10000 for technical reasons, and not because we decided that we really want it. We will always be able to transition to implicit deriving Typeable in the future, but transitioning back to explicit deriving Typeable loses compatibility with programs written for an earlier version of the compiler that had implicit deriving Typeable. So, seeing as we are in the RC phase for 7.10, my recommendation would be: - Keep the requirement to explicitly derive Typeable (and keep AutoDeriveTypeable, etc.) as in 7.10 RC 2 - Don't actually generate evidence terms when deriving Typeable. Instead mark the type as "Typeable-allowed". - When generating evidence in the Typeable solver, check that all of the types involved are marked as "Typeable-allowed". -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:64 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

Abstractly my main concern is that we've made a change (implicitly deriving Typeable everywhere) for the wrong reasons, and concretely my

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:64 rwbarton]: main fear, given the timing of this change, is that we'll find the new approach is untenable for some reason or other and be forced back into a world in which explicit deriving Typeable is required. Does artificially keeping require to explicitly derive `Typeable` during the 7.10 cycle actually help us identifying issues, rather than just releasing this into the wild with 7.10 and gather real-world data during 7.10's life-cycle? Fwiw, IIRC we wanted to turn on `AutoDeriveTypeable` by default anyway sooner or later. So this change just accomplishes that by a different mechanism, but the outcome is the same IMO. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:66 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I'm not particularly concerned about the possibility of this change breaking any existing program; that seems rather unlikely. What I am concerned about is the possibility of another bug like #10000 being discovered that forces us to abandon this "all types are Typeable" approach. It just seems like common sense to me to make large language changes like this at the start of a version's development, not one week before the last release candidate. (And I say large because there are probably tens of thousands of "deriving Typeable" out there. Yes I'd like to get rid of them too, but only if I could be reasonably sure that they won't have to be added back in for 7.10.2!) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:68 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): In that case perhaps we should advertise the new automatic Typeable deriving behavior as experimental in 7.10, so that users can decide whether they want to rely on it or not. Also, I think it's definitely correct that (as it is currently) warn- deriving-typeable ''not'' be enabled by `-Wall`. We can turn on the warning in 7.12. By the way, we may want to use a similar mechanism of generating evidence at the call site to handle #9557. For that problem, we would certainly need to track whether or not the class was derived at the definition site. So, I don't actually expect the effort to be useless. But the timing may be wrong here, unfortunately. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:70 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: highest => normal * differential: => Phab:D652 * milestone: 7.10.1 => 7.12.1 Comment: (In light of the merge for the immediate fixes, I'm demoting this bug and pushing it to 7.12.1, in case the discussion wants to continue. Simon has also indicated he wants to continue working on this area and redo some things, so we can leave this ticket open for that.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:72 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by goldfire): You've hit smack into a blind spot of a dark corner of GHC's type system: `*` and `Constraint` are actually considered interchangeable in Core. So this failure isn't terribly surprising. But it's indeed a bug. I don't think it should be too hard to fix. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:74 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by oerjan): * priority: normal => highest Comment: Sorry, but GHC 7.10.1 is still vulnerable. {{{ -- This exploit still works in GHC 7.10.1. -- By Shachaf Ben-Kiki, Ørjan Johansen and Nathan van Doorn {-# LANGUAGE Safe #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE ImpredicativeTypes #-} import Data.Typeable type E = (:~:) type PX = Proxy (((),()) => ()) type PY = Proxy (() -> () -> ()) data family F p a b newtype instance F a b PX = ID (a -> a) newtype instance F a b PY = UC (a -> b) {-# NOINLINE ecast #-} ecast :: E p q -> f p -> f q ecast Refl = id supercast :: F a b PX -> F a b PY supercast = case cast e of Just e' -> ecast e' where e = Refl e :: E PX PX uc :: a -> b uc = case supercast (ID id) of UC f -> f }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:76 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:77 diatchki]:

Hm, I think I can see what might be the issue, in fact there might be 2: * {{{() :: *}}} and {{{() :: Constraint}}} will end up having the same representation * Have to look at how we compute type reps for odd rank-2 types like {{{ ((),()) => () }}}

I'll have a go at a fix.

Although the automatic currying makes it disappear in this particular example, tuples like `((),())` also get the same representation as `*` and `Constraint`. I guess you currently need the `()` case to build any others, but I'm not sure if that should be counted on. (I also guess this all means Richard was right.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:78 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.12.1 => 7.10.2 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:80 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: 7.12.1 => 7.10.2 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:82 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7b042d5adabdb0fc06286db1a7f9cbf1e9fd1fbf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7b042d5adabdb0fc06286db1a7f9cbf1e9fd1fbf" Do not allow Typeable on constraints (Trac #9858) The astonishingly-ingenious trio of Shachaf Ben-Kiki, Ørjan Johansen and Nathan van Doorn managed to persuade GHC 7.10.1 to cough up unsafeCoerce. That is very bad. This patch fixes it by no allowing Typable on Constraint-kinded things. And that seems right, since it is, in effect, a form of impredicative polymorphism, which Typeable definitely doesn't support. We may want to creep back in the direction of allowing Typeable on constraints one day, but this is a good fix for now, and closes a terrible hole. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:84 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by goldfire): Simon, I see how your fix eliminates the problem, but do you know what caused it in the first place? It might be a tad drastic to just forbid `Typeable` instances over constraints. For example, should `Dict (Show Foo)` be `Typeable`? I think it's reasonable to assume so. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:86 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Looking at that fix, I'm not sure exactly what types trigger `isConstraintKind k` (does it include unapplied `Show`, say?), but wouldn't baking that single `Bool` test result into the `TypeRep` also fix things without making `Constraint`s un`Typeable`? Also, I am guessing you still technically have "`Typeable (=>)`" with identical `TypeRep` as `->`, although since they're different kinds I don't see how to exploit that - but that's what we thought of the `()` thing first. :P -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:88 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Shachaf and I experimented a bit, and the fix does *not* prohibit `Typeable` for unapplied type constructors. Together with the polykinded instance for type application, this can be used to construct, albeit awkwardly, `Typeable` instances for actual constraints. Example: {{{ shachaf> λ> let foo :: forall a b. (Typeable a, Typeable b) => Proxy a -> Proxy b -> Proxy (a b) -> TypeRep; foo _ _ _ = typeRep (Proxy :: Proxy (a b)) in foo (Proxy :: Proxy Ord) (Proxy :: Proxy Int) (Proxy :: Proxy (Ord Int)) shachaf> Ord Int }}} It is also possible to tease out constraint tuple constructors with type equalities (OK I'm not sure this was actually tested with HEAD, but I suspect it will work there): {{{ shachaf> > let x :: forall (a :: Constraint -> Constraint -> Constraint) b c. (a b c ~ (Ord Int, Show Int)) => TypeRep; x = typeRep (Proxy :: Proxy a) in x lambdabot> (,) }}} So my theory is that the only thing this fix *strictly* prohibits is `Typeable` for types involving nullary constraint constructors, including `()`. Luckily we don't see a way to get an exploit without `()`, for now. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:90 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Let me elaborate on my previous comment, especially the first suggestion, since my hunch is that it requires the smallest changes to implement to get back constraint `Typeable`s: * Instead of prohibiting constraint `Typeable`s, ''detect'' the specific case of `Typeable (() :: Constraint)` and give it a different instance from `Typeable (() :: *)`. == Why is this not less secure than the current fix? == As shown in comment [comment:90], the current fix only effectively prohibits `Typeable` constraints for ''nullary'' constraint constructors. For other constraints, while ordinary users are greatly inconvenienced, an attacker can instead get the instances for all the constructors used (only the ''exact'' kind of `Constraint` is disallowed, not e.g. `* -> Constraint`) and put them together with type application, whose `Typeable` instance needs to be polymorphic and therefore cannot reasonably check for `Constraint` kinds. All nullary constructors ''other'' than `()` are either kind monomorphic or have kind parameters to distinguish the `TypeRep`s, so they are useless to an attacker. == How is it better? == It allows `Typeable` for constraints, which some people think are useful. My feeling is that constraints, especially used as type parameters, shouldn't be considered impredicative except ''possibly'' if they contain `=>`. Prohibiting this case was the 3rd suggestion, but my hunch is that this is a more complicated change, and might, if desired, be better done with an overall overhaul disallowing `=>` more uniformly in the same contexts as quantified types, including disallowing splitting `a => b` into a type application. == How does it still seem a bit awkward? == It still allows some types to have identical `TypeRep`s, like `(,) :: * -> * -> *` and `(,) :: Constraint -> Constraint -> Constraint`. This is no change from the current fix, though. Fixing this entirely was the 2nd suggestion. It might perhaps be implemented directly, although my hunch is that it requires more work, because it needs checking for partial applications and thus more complicated kinds. I assume Edward's suggestion automatically implies this. == How is it sufficient? == With either my suggestion or the currently implemented fix, although some types still have identical `TypeRep`s, I believe they can never have identical ''kinds'' as well, and all cast operations require the actual kinds of the compared `Typeable`s to be equal. '''Proposition''': If two types `t` and `u` have the property: * `t` and `u` are distinct as Haskell types, but have the same `TypeRep` under the pre-fix system, and ''either'' both have the same kind or one has kind `*` and the other has kind `Constraint`; then one of the following holds: * They have two corresponding type arguments with the same property. * They are, in some order, `() :: *` and `() :: Constraint`. '''Proof''': If at least one of `t` and `u` does ''not'' have as its tycon one of the kind-ambiguous types `(), (,), ..., (->), (=>)`, then to have equal `TypeRep`s, their tycons and lists of kindreps must be identical, and the types themselves and all their arguments must have corresponding kinds. Thus to be different as types two of their corresponding arguments must have the property. If the tycons ''are'' kind-ambiguous then any arguments must have kind either `*` or `Constraint`. With no arguments, with the ''exception'' of `()`, the types must have different kinds that are not `*` or `Constraint`, a contradiction. Otherwise, the kinds of the tycons are determined by the kinds of the first arguments, and for `t` and `u` to be distinct, there must be two corresponding arguments with the property. ---- To justify the possibility of the 3rd alternative suggestion as well, the above proof can be adjusted to show that if the kinds of `t` and `u` are ''equal'', then types of the form `a -> c` and `b => c` must appear as corresponding arguments at some step. This is because all the other options preserve whether the kinds of the arguments are equal or different. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:92 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by diatchki): This should be fixed in HEAD now. Please give it a whirl, and let me know if you run into any more problems. The implementation should be what Richard discribed: * Constraints are OK * Impredicative types are not OK (not even things like `Eq Int => Int`) * Constraint and normal tuples should have different representations at all arities. A side-note: I couldn't figure out how to write the type constructor `(,) :: Constraint -> Constraint -> Constraint`, so I had to get creative with the testing. Is that intentional? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:94 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by simonpj): Comment for comment:94. Merge to stable branch {{{ commit d8d541d85defcf3bbbddaeee8cfac70b74f47ffc Author: Iavor S. Diatchki Date: Thu Apr 16 11:13:24 2015 -0700 Fixes (hopefully!) T9858 The changes are: 1. No impredicative types in `Typeable` 2. Distinguish normal tuples, from tuples of constraints.

---------------------------------------------------------------

d8d541d85defcf3bbbddaeee8cfac70b74f47ffc compiler/deSugar/DsBinds.hs | 6 +++- compiler/typecheck/TcInteract.hs | 34 +++++++++------------- testsuite/tests/typecheck/should_fail/T9858b.hs | 10 +++++++ .../tests/typecheck/should_fail/T9858b.stderr | 8 +++++ testsuite/tests/typecheck/should_fail/all.T | 1 + testsuite/tests/typecheck/should_run/T9858c.hs | 19 ++++++++++++ testsuite/tests/typecheck/should_run/T9858c.stdout | 1 + testsuite/tests/typecheck/should_run/all.T | 1 + 8 files changed, 58 insertions(+), 22 deletions(-) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:96 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by diatchki): Well, `=>` is not really a type-constructor, but rather a syntactic form. So I don't think it should ever appear alone, or partially applied, in a Haskell program. If we ever promoted it to an actual type-constructor status---which is an interesting idea---I think that we should assign it its own type- constructor and stop reusing the function-space constructor. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:98 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by simonpj): Under the fix of comment:96, the line {{{ g = f (Proxy :: Proxy (Eq Int => Int)) }}} would be rejected because there is no `Typeable (Eq Int => Int)`. So I think it looks fine as-is, don't you? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:100 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): We just realized you don't need much more than `i` there: {{{

i (Proxy :: Proxy (Eq Int => Int)) Eq Int -> Int }}}

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:102 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by ekmett): Removing the ability to unify `(c => t)` works for me. I have no uses of that in the constraints package, and it doesn't make a whole lot of sense anyways, as it really is a syntactic form. On the other hand, I have plenty of uses now of `Typeable` for `Constraint` kinded things. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:104 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"932f08677ca07f1793398e4c3456b81359728483/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="932f08677ca07f1793398e4c3456b81359728483" Test Trac #9858 comment:101 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:106 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by simonpj): Are we finally done with this ticket? Can we close it? oerjan?! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:108 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by simonpj): I think these examples will start to work when we get polykinded typeable, which is a consequence of what Richard is doing on his branch. What ''would'' be useful is if you produce a fresh set of test cases that you think should work, but don't. You can probably extract them from the 100 comments above, but I'd like to know what your short-list is! In fact make them into a new ticket, then we won't lose track. This one is too long and digressive now. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:110 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by dterei): * cc: dterei (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:112 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"130e93aab220bdf14d08028771f83df210da340b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="130e93aab220bdf14d08028771f83df210da340b" Refactor tuple constraints Make tuple constraints be handled by a perfectly ordinary type class, with the component constraints being the superclasses: class (c1, c2) => (c2, c2) This change was provoked by #10359 inability to re-use a given tuple constraint as a whole #9858 confusion between term tuples and constraint tuples but it's generally a very nice simplification. We get rid of - In Type, the TuplePred constructor of PredTree, and all the code that dealt with TuplePreds - In TcEvidence, the constructors EvTupleMk, EvTupleSel See Note [How tuples work] in TysWiredIn. Of course, nothing is ever entirely simple. This one proved quite fiddly. - I did quite a bit of renaming, which makes this patch touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. - I made constraint tuples known-key rather than wired-in. This is different to boxed/unboxed tuples, but it proved awkward to have all the superclass selectors wired-in. Easier just to use the standard mechanims. - While I was fiddling with known-key names, I split the TH Name definitions out of DsMeta into a new module THNames. That meant that the known-key names can all be gathered in PrelInfo, without causing module loops. - I found that the parser was parsing an import item like T( .. ) as a *data constructor* T, and then using setRdrNameSpace to fix it. Stupid! So I changed the parser to parse a *type constructor* T, which means less use of setRdrNameSpace. I also improved setRdrNameSpace to behave better on Exact Names. Largely on priciple; I don't think it matters a lot. - When compiling a data type declaration for a wired-in thing like tuples (,), or lists, we don't really need to look at the declaration. We have the wired-in thing! And not doing so avoids having to line up the uniques for data constructor workers etc. See Note [Declarations for wired-in things] - I found that FunDeps.oclose wasn't taking superclasses into account; easily fixed. - Some error message refactoring for invalid constraints in TcValidity }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:114 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D652 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bef2f03e4d56d88a7e9752a7afd6a0a35616da6c/ghc" bef2f03e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bef2f03e4d56d88a7e9752a7afd6a0a35616da6c" Generate Typeable info at definition sites This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T3294: GHC allocates 110% more (filed #11030 to track this) * T1969: GHC allocates 30% more * T4801: GHC allocates 14% more * T5321FD: GHC allocates 13% more * T783: GHC allocates 12% more * T9675: GHC allocates 12% more * T5642: GHC allocates 10% more * T9961: GHC allocates 6% more * T9203: Program allocates 54% less I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Requires update of the haddock submodule. Differential Revision: https://phabricator.haskell.org/D757 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:116 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D652, Wiki Page: | Phab:D757 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D652 => Phab:D652, Phab:D757 Old description:

{{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE AutoDeriveTypeable #-}

import Data.Typeable

data A = A

main = print $ typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy 'A) }}}

This returns `True`, but it should return `False`.

New description: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable data A = A main = print $ typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy 'A) }}} This returns `True`, but it should return `False`. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:118 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b Blocked By: | Blocking: Related Tickets: #10000 | Differential Rev(s): Phab:D652, Wiki Page: | Phab:D757 -------------------------------------+------------------------------------- Comment (by bgamari): There are some relevant performance comments in #12748. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9858#comment:120 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler