Re: [Haskell-cafe] GHC optimizations and unsafePerformIO - Was: Data.Typeable TypeRep Ord instance.
On 13:04 Sat 01 Jan , Felipe Almeida Lessa wrote: But, if you want to have a strang Ord instance, then why not have a strange unsafeTypeRepKey :: TypeRep - Int? Yes, that would be nice. But only if this really helps the compiler with optimising the code. Otherwise one could easily use unsafePerformIO. Andreas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC optimizations and unsafePerformIO - Was: Data.Typeable TypeRep Ord instance.
Thinking about this there might be one problem: Without having looked further into this I think perfomance might not be as expected. Using unsafePerformIO affects ghc's optimzations, doesn't it? So I wonder if it's a good idea (from a performance point of view) to use this. 2010/12/30 Andreas Baldeau andr...@baldeau.net: instance Ord TypeRep where compare t1 t2 = compare (unsafePerformIO (typeRepKey t1)) (unsafePerformIO (typeRepKey t2)) typeRepKey :: TypeRep - IO Int typeRepKey (TypeRep (Key i) _ _) = return i So the question is, if ghc could transform this to simply compare the keys throwing away unsafePerformIO and return. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC optimizations and unsafePerformIO - Was: Data.Typeable TypeRep Ord instance.
On 1 Jan 2011, at 12:38, Andreas Baldeau wrote: Thinking about this there might be one problem: Without having looked further into this I think perfomance might not be as expected. Using unsafePerformIO affects ghc's optimzations, doesn't it? So I wonder if it's a good idea (from a performance point of view) to use this. 2010/12/30 Andreas Baldeau andr...@baldeau.net: instance Ord TypeRep where compare t1 t2 = compare (unsafePerformIO (typeRepKey t1)) (unsafePerformIO (typeRepKey t2)) typeRepKey :: TypeRep - IO Int typeRepKey (TypeRep (Key i) _ _) = return i So the question is, if ghc could transform this to simply compare the keys throwing away unsafePerformIO and return. Wouldn't a much better plan simply be to take typeRepKey out of the IO monad? Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC optimizations and unsafePerformIO - Was: Data.Typeable TypeRep Ord instance.
On Saturday 01 January 2011 15:07:13, Thomas Davie wrote: On 1 Jan 2011, at 12:38, Andreas Baldeau wrote: So the question is, if ghc could transform this to simply compare the keys throwing away unsafePerformIO and return. Wouldn't a much better plan simply be to take typeRepKey out of the IO monad? I don't think so, it's in IO for a reason: -- | Returns a unique integer associated with a 'TypeRep'. This can -- be used for making a mapping with TypeReps -- as the keys, for example. It is guaranteed that @t1 == t2@ -- if and only if @typeRepKey t1 == typeRepKey t...@. -- -- It is in the 'IO' monad because the actual value of the key may -- vary from run to run of the program. You should only rely on -- the equality property, not any actual key value. The relative -- ordering of keys has no meaning either. -- typeRepKey :: TypeRep - IO Int That also means that an Ord instance based on the keys may change from run to run. It's probably not a problem for applications if it's only used for storing TypeReps in a Map and not for programme logic (if typeOf 'a' typeOf True then this else that), but it's somewhat fishy nevertheless. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC optimizations and unsafePerformIO - Was: Data.Typeable TypeRep Ord instance.
On Sat, Jan 1, 2011 at 12:42 PM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: I don't think so, it's in IO for a reason: -- | Returns a unique integer associated with a 'TypeRep'. This can -- be used for making a mapping with TypeReps -- as the keys, for example. It is guaranteed that @t1 == t2@ -- if and only if @typeRepKey t1 == typeRepKey t...@. -- -- It is in the 'IO' monad because the actual value of the key may -- vary from run to run of the program. You should only rely on -- the equality property, not any actual key value. The relative -- ordering of keys has no meaning either. -- typeRepKey :: TypeRep - IO Int That also means that an Ord instance based on the keys may change from run to run. It's probably not a problem for applications if it's only used for storing TypeReps in a Map and not for programme logic (if typeOf 'a' typeOf True then this else that), but it's somewhat fishy nevertheless. The reason for putting typeRepKey inside IO is changing between runs. So that means that compare should also be in IO. But, if you want to have a strang Ord instance, then why not have a strange unsafeTypeRepKey :: TypeRep - Int? Cheers! -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
