Welcome! Got a question? Do you have -Ypartial-unification turned on? Other FAQs: http://typelevel.org/cats/faq.html
yes, I can't quite remember what it did. The argument is that you could change the object that had state, and other ojbects would get the state change on using it. But somehow it was not OO...
I think there was an example using equations and variables
God it: Rx Reactive variables. His library is here.
I guess what I was thinking of falls probably in the space of premature optimisation. The thought was of sharing state with child actors, since On the same VM one does not really need message passing....
I personally use
for very rarely, and don't really recommend it if you're starting out with IO (it clouds the picture)
or is it considered bad to write it using infix ops?
infix ops are fine in scala 3 and scala 2 is mostly fine as long as you don't mind brackets.
and that's even more true once you move to
Resource and Stream
with
Resource, there is one place (the big resource in main where you build the world) where for is usually distinctly prettier than explicit combinators, so I'd use for if I was on my own. In a codebase shared with beginners I'd take the ugliness though and avoid for even then
(btw I doubt that this opinion on
for is shared by many people :) )
when you write in imperative style you have this
def vs val dichotomy (for being and doing), and we spend a lot of time discussing how FP shifts the focus to composing programs instead, where doing is expressed through combinators
for shifts you back to to the previous dichotomy (<- vs =), and now you have three layers of abstraction to deal with
an imperative dsl is translated to explicit programs which are then translated back to an imperative program at runtime
what you describe is the translation, not the mental model
the mental model when your write imperative programs is that you can either do, which you achieve with
val a = operation
or be (give a name), which you achieve with
def a = operation
for has the same mental model, you can either do with <-, or be with =
in both cases the default mode of operation is do
FP is different: the default mode of operation is be (so
val vs def doesn't matter) and do is expressed explicitly by combinators that compose programs
for {
a <- doThis
_ <- doThat(a)
}...doThis.flatMap(doThat) does (and generalises to doThis.race(doThat), doThis.orElse(doThat) etc
Ok, how to properly handle errors in for comprehensions?
case in point :)
you need to use an explicit operator, such as
handleErrorWith, which is more natural outside a for
if you write a small example I can show you
