[Haskell-cafe] Introducing Instances in GHC point releases
duncan.coutts at worc.ox.ac.uk
Fri May 22 04:49:53 EDT 2009
On Thu, 2009-05-21 at 21:30 -0500, John Goerzen wrote:
> 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?
The user guide, section "Creating a package", subsection "Conditional
> I imagine I may have to wrap the above in a __GLASGOW_HASKELL__ test for
> GHC 6.8 or something.
Again, there's no direct relationship between the version of ghc and the
version of Cabal (though there is some correlation).
> 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.)
True. People have been asking for a way to get cabal to invoke ghci with
all the right flags, which is a reasonable idea.
> > 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
Aye, it's ok for the people you don't upgrade things separately, and
those people are less likely to be able to work out how to fix things.
> 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?
Yes, we're loosening the connection between ghc and the non-core
packages, so that package maintainers make releases rather than the ghc
maintainers doing so.
What we're currently missing is a PVP checker: a tool to compare APIs of
package versions and check that it is following the PVP. Ideally, we
will have packages opt-in to follow the PVP for those packages that do
opt-in we have the PVP enforced on hackage using the checker tool. Since
the HP is almost certainly going to require packages to follow the PVP
then this should eliminate this class of mistakes. But it does need the
tool, and nobody is working on that at the moment.
More information about the Haskell-Cafe