Welcome! Got a question? Do you have -Ypartial-unification turned on? Other FAQs: http://typelevel.org/cats/faq.html
(A, B) => C
into A => B => C
(A => B) => (A => (B => C)) => (A => C)
A =>
into F[_]
F[B] => F[B => C] => F[C]
F[A => B] => F[A] => F[B]
, which is the key signature of the Apply
typeclass
f
and g
and noticing basically (A => B) => (A => C)
F[B] => F[C]
F[A] => F[B]
for consistency with the way things are usually written down
map: (A => B) => (F[A] => F[B])
ap: F[A => B] => (F[A] => F[B])
flatMap: (A => F[B]) => (F[A] => F[B])
A => B
(uneffectful), F[A =>B]
(effectful but no context sensitivity) and A => F[B]
(the effect can depend on the output of the previous computation, since A => F
I'll tell that to my manager when he starts about communication and presenting
ahahhaha :+1:
https://typelevel.org/cats/datatypes/either.html#solution-2-adts-all-the-way-down talks about error ADTs, what's SOP for common errors that you want to share across modules?
i think usually you have a separate ADT that is shared across modules. if you can have direct dependencies, then the upper ADT can refer directly to the module error types. otherwise you can cast or translate the module errors into something like Throwable
which the upper ADT wraps
foo: Foo => Bar
I can get a mFoo: M[Foo] => M[Bar]
, right?
map
and flatten
than flatMap