Most discussion is on Typelevel Discord: https://discord.gg/bSQBZA3Ced
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)
.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.
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
)
Option
), into a different type (say B
)
Option
is basically getOrElse
(sometimes such a thing is also called fold
)
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)
++
flatMap
, concurrently
etc
compile
is meant to evoke this translation process
compile.fold
, from which many others can be derived, compile.drain
, compile.toVector
, compile.foldMonoid
etc
compile
as a namespace, but I hope the name itself makes a bit more sense now
run
in previous versions, but I find compile
more evocative
IO
is a very special form of algebra
delay
cannot be simply seen as taking an A
and transforming it into IO