search

Gabriella439 / Haskell-MMorph-Library

Monad morphisms
BSD 3-Clause "New" or "Revised" License
47 stars 26 forks source link

Another breaking change in 1.0.8 #32

Closed bergmark closed 8 years ago

bergmark commented 8 years ago

ether fails builds against mmorph-1.0.8 but not 1.0.6:

$ cabal install ether-0.4.0.2/ --constraint='mmorph==1.0.6'
Resolving dependencies...
Configuring mmorph-1.0.6...
Building mmorph-1.0.6...
Installed mmorph-1.0.6
Configuring ether-0.4.0.2...
Building ether-0.4.0.2...
Installed ether-0.4.0.2
$ cabal install ether-0.4.0.2/ --constraint='mmorph==1.0.8'
Resolving dependencies...
In order, the following will be installed:
ether-0.4.0.2 (reinstall) (changes: mmorph-1.0.6 -> 1.0.8)
Warning: Note that reinstalls are always dangerous. Continuing anyway...
Configuring ether-0.4.0.2...
Building ether-0.4.0.2...
Failed to install ether-0.4.0.2
Build log:
cabal: Entering directory 'ether-0.4.0.2/'
Configuring ether-0.4.0.2...
Building ether-0.4.0.2...
Preprocessing library ether-0.4.0.2...
[ 1 of 30] Compiling Control.Ether.Util ( src/Control/Ether/Util.hs, dist/dist-sandbox-e1a1fad2/build/Control/Ether/Util.o )
[ 2 of 30] Compiling Control.Monad.Trans.Ether.Tagged ( src/Control/Monad/Trans/Ether/Tagged.hs, dist/dist-sandbox-e1a1fad2/build/Control/Monad/Trans/Ether/Tagged.o )

src/Control/Monad/Trans/Ether/Tagged.hs:50:48: error:
    • No instance for (MFunctor trans)
        arising from the 'deriving' clause of a data type declaration
      Possible fix:
        use a standalone 'deriving instance' declaration,
          so you can specify the instance context yourself
    • When deriving the instance for (MMonad (TaggedTrans tag trans))
cabal: Leaving directory 'ether-0.4.0.2/'
cabal: Error: some packages failed to install:
ether-0.4.0.2 failed during the building phase. The exception was:
ExitFailure 1
Gabriella439 commented 8 years ago

Interesting. Apparently this is due to the recent addition of PolyKinds. I thought that would be a non-breaking change but it seems to be interfering with type inference here

I'll revert the change and release as mmorph-1.0.9 and blacklist mmorph-1.0.8

hvr commented 8 years ago

It's interesting to finally get an example of enabling PolyKinds breaking consumers. I've been wondering how likely something like that would be...

RyanGlScott commented 8 years ago

Strictly speaking, the breakage wasn't the fault of mmorph, but rather it's due to a GHC bug present in 8.0.1 and earlier. In fact, I verified that ether compiles with the poly-kinded MFunctor on GHC 8.0.2 and later.

RyanGlScott commented 8 years ago

If we did wish to support poly-kinded MFunctor, we could submit a patch to ether that works around that bug. (We'd just have to make sure MFunctor wasn't a derived instance on sufficiently old versions of GHC.)

RyanGlScott commented 8 years ago

We'd also need to patch ChannelT.

Gabriella439 commented 7 years ago

I guess my question is: now that the problem is fixed in GHC 8.0.2 do I need to bump the major version number if I reintroduce the original change or is it safe to do a minor release?

RyanGlScott commented 7 years ago

Going from a mono-kinded class type signature to a poly-kinded one is, in some sense, an API change. Ideally, it'd be a harmless one, but in practice there tends to be little interactions in kind inference that inevitably cause some things to break (and that's aside from GHC bugs like the one noted in https://github.com/Gabriel439/Haskell-MMorph-Library/issues/32#issuecomment-261808442).

My vote is for a major version bump to be on the safe side.

RyanGlScott commented 7 years ago

Woohoo! mmorph-1.1.0 has been released with this change restored.

I've submitted PRs for ether and ChannelT to account for GHC Trac #11837.