@matfournier Sounds like just handling the error might be enough, you can find an example of this in https://github.com/profunktor/fs2-rabbit/blob/master/core/src/main/scala/dev/profunktor/fs2rabbit/resiliency/ResilientStream.scala
fs2 has
HotSwap for chains of resources, but not sure how the wiring would look like for your case though. See functional-streams-for-scala/fs2#1667
Just be aware that IIRC the semantics of it are that if it's bracketed, all the resources will shutdown and then reopen IIRC
why not, clarifying scaladoc is always useful
@SystemFw, as suggested by the CONTRIBUTING.md, I post a kind reminder of the PR below
functional-streams-for-scala/fs2#1837
@LukaJCB Yeah that's my go-to right now since it iterates only once. I know I probably don't have to worry about it RE: turning it into a
List first, but it just gives me the heebie jeebies to think about even the possibility of it being more inefficient than it needs to (even if it'll likely get JITted, my brain doesn't fully internalize that)
Can someone give me an intuition of what
.compile does for a stream? It seems like in code examples we see things like s.compile.drain or s.compile.last or something; when I see a method name like .compile I think that it may be optimizing the stream somehow (by inspecting the object graph) - but if that were the case, it sort of seems like drain or last would need to come before compile in that chain, and compile would turn the Stream[F, O] into an F[O] or something.
The namespacing technique works better for auto-complete than a naming convention based technique (e.g. suffixing or prefixing all Stream to F methods with some common string)
let me know if you're interested in knowing more
basically in FP there is this technique of design through algebras (I'm talking here in the most general sense, even more general than tagless final)
and it basically works like this
you have a type (say
Option), some introduction forms (ways of getting "into" the algebra, for example Option.empty, and .some), some combinators (building building programs in your algebra from smaller programs, like Option.map, Option.flatMap, Option.getOrElse etc) , and potentially some laws (eg. anyOption.flatMap(Option.empty) == Option.empty)
makes sense so far?
but the question is
what does it mean to "run" programs in Option?
do you have an idea there?
"running" an algebraic programs amount to transforming the carrier type (
Option), into a different type (say B)
the shape of this transformation depends on the shape of the language, and in the case of
Option is basically getOrElse (sometimes such a thing is also called fold)
the trasformation functions is called an eliminator, in the context of an algebra
so to recap, in an algebra
- you have a type
- you have introduction forms, that take types and convert to the algebra type
- you have combinators, which are the meat of it, and allow you to build programs compositionally
- you have laws, potentially
- you have elimination forms, which transform the algebra type to another type, and correspond to our notion of "running"
now, this pattern is very very general, and appears in many forms, and can be also abstracted over in many forms (like tagless final)
unsurprisingly,
Stream also follows this pattern
Stream is the type
emit, eval and co. are the introduction forms (take types that aren't stream, and convert them to stream)
then you have the myriad of combinators, like
++ flatMap, concurrently etc