search

composewell / streamly

High performance, concurrent functional programming abstractions
https://streamly.composewell.com
Other
869 stars 66 forks source link

MonadTrans vs Category instances for unfolds and folds #960

Closed harendra-kumar closed 10 months ago

harendra-kumar commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 10 months ago

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.