Ian Lynagh wrote:
On Fri, Oct 10, 2008 at 03:54:07PM -0700, Duncan Coutts 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
On Fri, 2008-10-10 at 15:34 -0700, Don Stewart wrote: the versioning policy so we need to follow it ourselves in our base libs.
I don't think that that really helps. If you're going to depend on base 3.1, you might as well just depend on base 4 and be more future-proof. The base-compat package needs to claim to have the same API as the old base, because the point is that things just keep on working (except in the few cases, like the Arrow split, where that isn't possible).
Hmm, this is quite annoying. We simply *can't* provide the same API as base-3.0.2 without defining a new Arrow class, and that would kill compatibility with base-4. On the other hand, we did know this could happen (changes to datatypes also cause the same problem), it's the tradeoff with trying to provide base-3 as a compatibility layer over base-4. So the options are: * if we are honest and call it base-3.1, then everyone else has to lie and use dependencies like base==4.*. If they use dependencies like base==4.0, which are more correct, then these packages will break in GHC 6.12 if we have to ship base-4.1 rather than 4.0. * we lie (a bit) and call it base-3.0.3. so the total amount of dishonesty is reduced if we pick the second option :-) Perhaps we've found a use for the second digit of the major version number. Cheers, Simon