I hope that typeRepKey is no longer in the IO monad (for the simple reason to teach me that the key can change between session). This forced me to use unsafePerformIO to make a typeable boxed type of instances of Ord an instance of Ord (to put it in a Map). Or did I miss something and I can do better anyhow? e.g.: class (Ord s, Typeable s) => Selector s data GenSelector = forall s . Selector s => GS s instance Ord GenSelector where compare (GS a) (GS b) = if typeOf a == typeOf b then compare (fromJust (cast a)) b else compare (unsafePerformIO $ typeRepKey $ typeOf a) (unsafePerformIO $ typeRepKey $ typeOf b) Jürgen Nicklisch -- View this message in context: http://haskell.1045720.n5.nabble.com/The-Typeable-class-is-changing-tp457603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

This will affect snap-core and heist, of the things I've provided Typeable instances for. In snap-core, deriving makes it use the internal module name, rather than the canonical location of the type. This causes issues with the Hint library, so it's worked around by using a manual instance of Typeable. Alternatively, heist involves a monad transformer. "deriving Typeable" fails for monad transformers, because it can't handle TyCons with arguments of kind other than *. So, this change will hit me for two different reasons, and sadly involve using CPP to control how things are compiled. Carl On Mon, Jul 11, 2011 at 11:18 AM, Yitzchak Gale wrote:

Simon Marlow has announced[1] on the Haskell Libraries list that the Typeable class is changing.

The standard way to create a Typeable instance is just to derive it. If you do that, you will not be affected by this change.

But it seems that many packages create Typeable instances by explicitly using mkTyCon. If your package does this, it will eventually break, after a deprecation period.

Please respond to this thread if you own a package that will be affected by this change.

Can someone who has quick access to the entire contents of Hackage please do a grep and find out exactly which packages on Hackage will be affected? Thanks.

-Yitz

[1] http://www.haskell.org/pipermail/libraries/2011-July/016546.html

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 7/11/11 11:18 AM, Yitzchak Gale wrote:

The standard way to create a Typeable instance is just to derive it. If you do that, you will not be affected by this change.

This is only the "standard way" if one is willing to sacrifice Haskell98 or Haskell2010 compatibility by using the non-standard DeriveDataTypeable extension.

But it seems that many packages create Typeable instances by explicitly using mkTyCon. If your package does this, it will eventually break, after a deprecation period.

I have done this in at least one of my packages (type-level-natural-number) because I wanted to keep my library compatible with Haskell2010 rather than relying on GHC-specific extensions. To be clear, I think that the new Typeable is an improvement and don't mind migrating my package to use it, I just get the sense after reading the linked exchange that those discussing this have just assumed that the standard way to use Typeable *should be* to use "deriving Typeable" and are missing what I suspect is a major reason why people avoid using it, which is to reduce dependence on GHC-specific extensions. Again, this not a complaint or an objection at all, I'm just sharing my own thoughts on the matter. :-) Cheers, Greg

I wrote:

Please respond to this thread if you own a package that will be affected by this change.

Responding to my own request, here are some more packages that use mkTyCon explicitly: Ashley Yakeley's time package, which is part of the Haskell Platform. My timezone-series package, because it is based on the time package. John Millikin's xml-types package. My dtd-types and dtd-text packages, because they are based on the xml-types package. -Yitz