MonadTrans vs Category instances for unfolds and folds

[harendra-kumar]

For MonadTrans instance we will need the types to be Unfold a m b and Fold a m b but then we will need a newtype for Category /Arrow/Profunctor instances. Which one should we have by default?

Based on this we have to decide whether to keep the newly introduced Category/Arrow instances in 0.8.0 for unfolds or not.

[harendra-kumar]

I am not sure how useful a MonadTrans would be for Fold/Unfold types. We can possibly introduce FoldT and UnfoldT in future if that is required.

[hasufell]

I vote for MonadTrans, especially for Parser. I could have used it here: https://github.com/hasufell/streamly-yaml/blob/bfd1da498588af906cbc5d3bb519f1ccdf7ad63e/yaml-streamly/src/Data/Yaml/Internal.hs#L218

And instead needed to implement MonadReader and MonadState.

[harendra-kumar]

Let's go for the possibility of MonadTrans for folds and parsers, and change the types to Fold a m b, Parser a m b. This would be a breaking change for folds. Though only type signatures will have to be changed. This will make folds similar to streams which also have a MonadTrans.

[harendra-kumar]

Unfolds should probably not even be Applicative/Monads as fromPure/fromEffect are a bit contrived functions. They fit naturally to Category. So we can keep them as it is i.e. Unfold m a b.

[harendra-kumar]

Parsers are changed to Parser a m b. Folds are not performant/CPS Monad, we can keep folds as it is until we have a need for it.