Add a fork/major version for GHC >= 8.6

[treeowl]

As you've already seen, GHC 8.6 wins

instance (MFunctor f, MFunctor g, forall m. Monad m => Monad (g m))
    => MFunctor (ComposeT f g)

But it has more to offer. We can change the MonadTrans instance to the (effectively) less-constrained, and sometimes more efficient,

instance (MonadTrans f, MonadTrans g, forall m. Monad m => Monad (g m)) => MonadTrans (ComposeT f g)
  where
    lift = ComposeT . lift . lift

and then even change the type of hoist to

    hoist :: (Monad m, Monad n) => (forall a . m a -> n a) -> t m b -> t n b

which allows some important instances including streamly streams and Church-style free monad transformers.

Basically, aside from the fact that QuantifiedConstraints is a pain and a half for instance resolution, everything gets much nicer.

[Gabriella439]

Yes, I would like to take advantage of QuantifiedConstraints in some way. It's a much nicer solution to the problem

[Gabriella439]

So I was thinking about ways to do this non-disruptively, and one possible solution is to just add a new newtype (e.g. ComposeT2 for lack of a better name) with the new instance and then users can also use deriving via (ComposeT2 f g) to get the desired MonadTrans instance

[treeowl]

The problem is we really want to change the type of hoist, and that's inherently disruptive.

On Sat, Sep 28, 2019, 11:13 AM Gabriel Gonzalez notifications@github.com wrote:

So I was thinking about ways to do this non-disruptively, and one possible solution is to just add a new newtype (e.g. ComposeT2 for lack of a better name) with the new instance and then users can also use deriving via (ComposeT2 f g) to get the desired MonadTrans instance

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Gabriel439/Haskell-MMorph-Library/issues/50?email_source=notifications&email_token=AAOOF7OAUVBE4KR72FBWJZTQL5YCDA5CNFSM4I24TQ22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD723XXQ#issuecomment-536198110, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOOF7PQM6SLKFV36IH5BNLQL5YCDANCNFSM4I24TQ2Q .

[turion]

But the change in hoists type is backwards compatible, because instances of the old version will still be instances of the new version, right?

[Gabriella439]

In general, any change to the type of hoist will be backwards-incompatible, either for people who author instances or for people who consume instances.

In this specific case, the proposed change to the type of hoist would be backwards-incompatible for consumers because we're adding a constraint

[turion]

In this specific case, the proposed change to the type of hoist would be backwards-incompatible for consumers because we're adding a constraint

Makes sense. Maybe a transition scheme with a cabal flag new-hoist makes sense:

• Current version: Keep hoist :: Monad m => ...
• Version +1:
  • Introduce cabal flag new-hoist with default false
  • When flag is disabled hoist :: Monad m => ..., when it's enabled, hoist :: (Monad m, Monad n) => ..., with a haddock note that people are encouraged to switch the flag on
• Version +2:
  • Make flag default true
  • Add a deprecation note to hoist :: Monad m => ...
• Version +3: Remove flag and old version

This is extra effort during versions +1 and +2, but removes the need for a fork and prevents the issue of being stuck eternally.

[Gabriella439]

I'm personally still reluctant to change the type of hoist because it's still not clear that we need the extra Monad constraint

[turion]

    hoist :: (Monad m, Monad n) => (forall a . m a -> n a) -> t m b -> t n b

which allows some important instances including streamly streams and Church-style free monad transformers.

That I don't understand. Wouldn't you need MInvariant for this (https://github.com/Gabriel439/Haskell-MMorph-Library/pull/1).

[turion]

I'm personally still reluctant to change the type of hoist because it's still not clear that we need the extra Monad constraint

Ah, right. The transition scheme could still be applied to changing the ComposeT type signature.

[treeowl]

@turion, no, I take a look in the free package.

[turion]

@turion, no, I take a look in the free package.

Ah, yes, for Church-style free monads it seems like Monad n is needed. But for streamly I believe even Monad n is not enough, and you'd need MInvariant or so.