Build streamly with ghc-9.6.1

[rnjtranjan]

No description provided.

[rnjtranjan]

Build is failing due MonadTrans definition change:

• https://hackage.haskell.org/package/transformers-0.5.6.2/docs/Control-Monad-Trans-Class.html#t:MonadTrans

• https://hackage.haskell.org/package/transformers-0.6.1.0/docs/Control-Monad-Trans-Class.html#t:MonadTrans

[Bodigrim]

streamly/src/Streamly/Internal/Data/Stream/Parallel.hs

Lines 433 to 437 in 68b2d87

	newtype ParallelT m a = ParallelT {getParallelT :: K.StreamK m a}
	instance MonadTrans ParallelT where
	{-# INLINE lift #-}
	lift = ParallelT . K.fromEffect

streamly/src/Streamly/Internal/Data/Stream/Parallel.hs

Lines 497 to 501 in 68b2d87

	instance MonadAsync m => Monad (ParallelT m) where
	return = pure
	{-# INLINE (>>=) #-}
	(>>=) = bind

The basic problem is that ParallelT is not an unconstrained monad transformer such that forall m. Monad m => Monad (ParallelT m), and thus does not match the definition of MonadTrans from transformers-0.6+.

[harendra-kumar]

These types (ParallelT etc) were deprecated in the last release. We can either find a workaround to keep them working for some more time or just stop support for newer compilers if it is too hard or impossible.

[harendra-kumar]

Do not comment out parts of the code. Either a whole module is in or out. In fact we should have the whole set of modules using IsStream out together. Otherwise it will be extremely confusing and messy for users.

[rnjtranjan]

looks good.

[hasufell]

Can this be backported to older streamly versions? (more specifically 0.8).

[harendra-kumar]

Which version do you want it for? And what is the motivation? Can we use a newer streamly version instead?

The problem is that it is a breaking change which requires a major version bump. It will be confusing if things break just because a newer transformer version was chosen by cabal automatically.

[hasufell]

Which version do you want it for?

0.8

Can we use a newer streamly version instead?

I'd have to migrate two packages, which I absolutely don't have bandwidth for since the API of streamly breaks too often and too severely with every major release:

• https://hackage.haskell.org/package/yaml-streamly
• https://hackage.haskell.org/package/ghcup

[harendra-kumar]

0.9.0 was an exception due to some fundamental changes in concurrency API. let me check how easy or difficult it would be to migrate these. If we send a PR migrating these would it be fine?

[hasufell]

If we send a PR migrating these would it be fine?

I don't want to risk regressions at the moment and my test suites are not good enough.

[harendra-kumar]

How do we go about it then? The only option is to release a 0.8.x with the breaking change. Is there a better way?

[hasufell]

Ah shoot... I missed that the fix itself involves a breaking change. I guess then it's not possible.

Going forward you should consider using the first version component more, so that such intermediate bumps are possible. Or just bump 2-3 increments of the second version component instead of the next.

[harendra-kumar]

One possible option is to upload a new 0.8.x with a build flag ghc96 which you can enable in your build. Will that work?

[hasufell]

One possible option is to upload a new 0.8.x with a build flag ghc96 which you can enable in your build. Will that work?

Well, flags really shouldn't affect exposed API.

The only option seems to be migration, so I'll be stuck with GHC < 9.6 for a while.

[harendra-kumar]

Ok, let's try yaml-streamly first.

[hasufell]

Hm... from what I understand, the patch here has nothing to do with GHC-9.6, but with transformers. But it's possible to depend on a different than "shipped-with-ghc" transformer package.