Fix78

[cheecheeo]

Use mtl-2.2.1.*, exceptions in haskell-cgi, builds successfully with compilers: 7.4.2, 7.6.3, 7.8.3 [1]

@cartazio please review, then I'll merge to master and then upload to hackage with major version bump.

[1] https://travis-ci.org/cheecheeo/haskell-cgi/builds/32927123

[cartazio]

I'll look at it a teeny bit more closely, but do you need 2.2.1.* rather than 2.2.* as your MTL constraint?

[cheecheeo]

@cartazio please take another look.

[cartazio]

hrm a few thoughts

a) looks like we're dropping support for GHC < 7.4, which is fine i guess, if so we should kill all the clauses for split-base and also base < 4.5 right? (i might be mixing up version numbers, but its something like that)

b) do we need mtl 2.2.* , or could we (via depping on transformers-compat) allow mtl 2.1 or 2.2? (or need we only transformers compat rather than forcing a choice in MTL version?) c) mtl 2.2 requires transformers 0.4, which means that you might run into pain on ghc 7.8 (which bakes in 0.3) if your'e also linking to ghc builtin libs that are using it (i forget if any do, so this might be a spurious concern)

d) package upper bounds, they are a thing, and are needed for pvp happiness (ignoring certain parties feelings on that topic)

e) i'm trying to figure out my thoughts on the ErrorT-> ExceptT change, and whether that should be in the first fixed up release (because of migrating to using the exceptions, the api is a breaking change anyways).

[cartazio]

so i guess i'm roughly suggesting the initial release try to support as large a range of versions as possible? otoh, ErrorT IS deprecated in 2.2. blah this is tricky to think about

[cartazio]

either way, by dint of moving to using the exceptions package, its going to be a major version bump right?

[cheecheeo]

Yes, for the type of (for example) throwCGI changing is forcing a major version bump.

[cheecheeo]

b), e) are not fixable due to the deprecation of Control.Monad.Error. Recall that the reason we're going down this road with exceptions is because of deprecation in MonadCatchIO it would be too double-standardy to allow deprecation in one case but not the other. What do you think?

[cartazio]

hrm, would mtl < 2.3 be reasonable? though we can edit bounds on hackage now. So it looks like my main objection / worry is about stuff thats easy to change post facto.

either way, this is gonna be a major version bump i guess.

[cheecheeo]

I think it needs to be mtl >= 2.2.1 because of import Control.Monad.Except (MonadError(..)), an upper bound of < 2.3 sounds fine to me.

[cartazio]

yeah that looks sane based upon the MTL change log https://hackage.haskell.org/package/mtl-2.2.1/changelog

[cartazio]

i think its safe to cut a new major version bump and tag it etc and push it assuming CI goes through green!

probably want to update the issue/repo URLS right?

[cartazio]

then push/announce sometime tomorrow? dont forget to make sure the haddocks look good :)

[cheecheeo]

once this goes green, I'll merge into master then make a new release branch

repo URL is up to date on master, I'll add an issue url