Re: [Haskell-cafe] The Typeable class is changing
On Tue, Jul 12, 2011 at 5:30 AM, Jon Fairbairn wrote: >> So, this change will hit me for two different reasons, and sadly >> involve using CPP to control how things are compiled. > > so that shouldn’t be necessary. CPP will be necessary, since we want to support older versions of the base library as well (which obviously don't have myTycon3). -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Typeable class is changing
Jon Fairbairn wrote: > There’ll be a replacement for mkTycon (mkTycon3), so you can > still do manual instances… Right, it should be easy to fix manual Typeable instances. It's just that if no action is taken, they will eventually break. So it's good to make sure that there is public awareness, and for the community to have awareness about the scope of the changes that need to be made. Also, we should clarify that AFAIK everyone agrees that this is a welcome improvement to Typeable. We are just trying to smooth the upgrade process so that it does not cause unexpected inconvenience to users of the various libraries on Hackage. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Typeable class is changing
Carl Howells writes: > 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. There’ll be a replacement for mkTycon (mkTycon3), so you can still do manual instances… > So, this change will hit me for two different reasons, and sadly > involve using CPP to control how things are compiled. so that shouldn’t be necessary. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Typeable class is changing
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Typeable class is changing
At Mon, 11 Jul 2011 21:18:30 +0300, Yitzchak Gale wrote: > > Please respond to this thread if you own a package > that will be affected by this change. iterIO uses mkTyCon for the simple reason that ((Typeable t, Typeable m) => Iter t m) is Typeable1 and there is no automatic way of deriving Typeable1. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Typeable class is changing
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Typeable class is changing
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 > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Typeable class is changing
On Mon, Jul 11, 2011 at 1:22 PM, jutaro wrote: > 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). If it's implementation dependent then I see no reason for it to be in IO (this was mentioned on another ML). On the other hand, something that changes run-to-run strikes me as good to keep in IO, otherwise I'd be too tempted to serialize & save it for some purpose and get confused while a later read was corrupt. Cheers, Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Typeable class is changing
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-tp4576031p4576350.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The Typeable class is changing
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
