Most discussion is on Typelevel Discord: https://discord.gg/bSQBZA3Ced
but its not used in Stream
the
Stream monad instance (which is on O)
is better for control flow
the
Pull monad instance (which is on R) is better for stateful combinators (so for the actual "streaming" aspect)
you can obviously write a combinator in
Pull
by recursing and "transferring some state", as you say
and once you're done you convert to Stream
that's how Stream's stateful combinators are done
it returns
Pull[F, Nothing, Option(Chunk[O], Stream[F, O])]
so that emits nothing?
similar to list uncons
then you flatMap to get that
and you have the stream to decide what to do next (recursively)
yeah, in most cases that's how it's used
note that in Haskell most streaming libraries have 3 type params
one for output, one for result
and the forces you to pick one as the "blessed" one for your Monad instance
but different scenarios work well with difference instance
as I said, an instance on O makes
Stream.flatMap behave like a List, and it's great for control flow
an instance on R makes it behave like an iterator, and it's great for stateful combinators and streaming
fs2 separates that into 2 types (Stream and Pull), that wrap the same Algebra (so there' s only one interpreter for both Stream and Pull)
I was confused as to why we needed both at first
but this is actually one of my favourite design decision in the whole of fs2
to return the next page to the next Pull and then emit?
you can do it like that
however,
Stream exposes higher-level combinators over Pull
for example,
unfoldEval is perfect for pagination
and I recommend you use Stream as your first choice
try writing
Stream.take by hand
then see how it's written in the lib