Duncan Coutts wrote:
On Thu, 2009-05-21 at 15:22 -0700, Alexander Dunlap wrote:
Since those types come out of the time library, and that library's version *has* been bumped (I assume), couldn't you use Cabal to condition on the version of the time library to determine whether or not to have CPP set a -DTYPEABLE_IN_TIME flag, and then #ifdef out your versions of the instances?
I was about to suggest this:
#if MIN_VERSION_time(1,1,2) ... #endif
That would be slick. I'll give that a whirl. What version of Cabal does GHC 6.8 come from, and where can I read about the above feature? I imagine I may have to wrap the above in a __GLASGOW_HASKELL__ test for GHC 6.8 or something. Though if *cabal* and not GHC generates it, isn't that a bit hurting to my portability? (Can't just ghc --make with it, or ghci on it directly anymore, etc.) May be a needed tradeoff though.
because Cabal 1.6+ generates these cpp macros for you. Note that relying on the value of __GLASGOW_HASKELL__ would be wrong because the version of the time library is not directly related to the version of ghc.
Yeah, but when you've got nothing else to go on, it sometimes works in a pinch.
However, I note that all the recent versions of time are 1.1.2.x which means it didn't bump the API version when it added the instances.
Ashley, I'll forgive you this time ;-) I guess my larger point is just a plea to the community: please be really careful about what you do to GHC in point releases. This is not the first issue that has screwed me in the GHC 6.10.x point releases. GHC (and the community) used to be really good about this. Is there something causing a regression here, or is it my imagination?