On Fri, 2008-10-10 at 15:34 -0700, Don Stewart wrote:
arrows fails due to:
[ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o )
Control/Arrow/Transformer/CoState.hs:24:29: Module `Control.Arrow' does not export `pure'
Even though cabal-install decided to use base-3.0.3.0
So that means base-3 is *not* exporting quite the same interface as last time. Were we aware of this?
Note that this means that base-3 should have the version number 3.1.x.y because there is at least one incompatible api change. We're promoting the versioning policy so we need to follow it ourselves in our base libs. On this issue, we've discussed before that packages should be able to opt-into the versioning policy and that if they do we can have our tools suggest that dependencies on such packages should take a particular form. For example depending on and api version ==1.1.* and not upward open ranges, or mistakes like parsec <= 2.1.0.0. There's not time to implement these suggestions in the tools for 6.10 however we do have the opportunity to annotate the packages that we believe do follow the versioning policy. We can then get our tools make use of this information in the coming months. So my suggestion is that in time for 6.10.1 we add something like the following to the .cabal files for all the core and extra packages: x-follows-version-policy: This is free. It doesn't involve any api changes in Cabal or anything else. All such "x-" extension fields are allowed by cabal and collected into a name/value pair list. If it seems to work out then we can make it a proper field (and at that time we can argue what colour we should paint it). Sound sensible? We can send patches to add this to the core + extra packages. I think it'd be good to do this now because while the base 3 - 4 thing has gone fairly well this time, future changes would be much easier if we were using more sensible dependency constraints. I think the best way to communicate that to developers is through warnings generated by their tools. Yes that's right, cabal-install is a channel for package QA propaganda. Duncan