These are chat archives for typelevel/cats

20th
Jul 2016
Greg Pfeil
@sellout
Jul 20 2016 05:44
I’m depending on 0.6.1, and it’s telling me “object FunctionK is not a member of package cats.arrow” … but it is, right?
Adelbert Chang
@adelbertc
Jul 20 2016 07:20
@sellout i dont think the rename made it for 0.6.0
itll prob be 0.7.0
Cody Allen
@ceedubs
Jul 20 2016 10:11
@sellout to clarify @adelbertc’s statement, it’s still called NaturalTransformation in 0.6.1
~> is an alias for both versions though
Denis Rosca
@denisrosca
Jul 20 2016 11:02

Hello guys,
I have a bit of a problem with the following code:

val result: Writer[List[String], Option[ProcessedData]] = for {
    data <- getData() // this returns Writer[List[String], Option[Data]]
    processed <- process(data) // takes a parameter of type Data and returns Writer[List[String], Option[ProcessedData]]
} yield processed

The problem is that data is of type Option[Data] instead of the expected Data, so obviously the compiler complains.
Is there any way to do this in a for comprehension and keep the compiler happy?

Diego E. Alonso Blas
@diesalbla
Jul 20 2016 11:36
@denisrosca If you are keen on a for comprehension, I would suggest a Monad transformer. https://github.com/typelevel/cats/blob/master/docs/src/main/tut/optiont.md
type WL[A] = Writer[List[String], A], and then OptionT[WL, A], with A being Data or ProcessedData
Cody Allen
@ceedubs
Jul 20 2016 11:37
@denisrosca I think conceptually what you want is data.traverseM(process) on the second line. There might be some type inference issues, though.
https://github.com/milessabin/si2712fix-plugin will probably fix the type inference issues if there are any
Cody Allen
@ceedubs
Jul 20 2016 11:42
as @diesalbla mentioned, a monad transformer is also an option. If you are going to have Option on the right side on a lot of methods like this then it will probably be worth it. If this Option is a one-off situation, then traverseM might be preferable
Peter Neyens
@peterneyens
Jul 20 2016 11:52
We don't seem to have a Traverse instance for WriterT / Writer ?
Cody Allen
@ceedubs
Jul 20 2016 11:55
hmm. We should add one if we don’t. But in this case I’m talking about calling traverseM on an Option
(which would use the Applicative instance for Writer)
Peter Neyens
@peterneyens
Jul 20 2016 11:55
Ah ok, I see
Cody Allen
@ceedubs
Jul 20 2016 11:56
good fine though @peterneyens. I’ll create a GitHub issue for it.
Peter Neyens
@peterneyens
Jul 20 2016 11:56
seems it is already in #620
Cody Allen
@ceedubs
Jul 20 2016 11:56
ah I see
I’m not even seeing a Traverse instance for Tuple2. Are we missing that too?
Peter Neyens
@peterneyens
Jul 20 2016 11:59
I think a lot of instances of tuple2 are missing
Cody Allen
@ceedubs
Jul 20 2016 11:59
yeah I think you are right
Peter Neyens
@peterneyens
Jul 20 2016 11:59
We have only Bitraversefor the moment
Cody Allen
@ceedubs
Jul 20 2016 11:59
probably want to add Traverse and Comonad
I’ll create an issue for this one then :)
#1219
At the moment I’m distracted with experimenting with a FunctorFilter to add to #1148 to unify TraverseFilter and MonadFilter so if someone wants to take #1219, I won’t fight you for it :D
Peter Neyens
@peterneyens
Jul 20 2016 12:04
With filter, collect, mapFilter ?
Cody Allen
@ceedubs
Jul 20 2016 12:05
yeah
there are a couple laws that I think make it a reasonable type class to separate out
and it might even ease a bit of pain we’ve had with weak/strong MonadFilter laws, but I’m not sure.
Peter Neyens
@peterneyens
Jul 20 2016 12:09
That would be nice
Cody Allen
@ceedubs
Jul 20 2016 12:10
hmm or maybe the weak/strong laws issue is a reason that I shouldn’t be going down this path...
I guess I’ll continue the experiment and see how it pans out :)
with a FunctorFilter in place, the empty[A] on MonadFilter starts to seem sort of arbitrary to me
Cody Allen
@ceedubs
Jul 20 2016 12:16
like maybe there should just be FunctorFilter and MonadCombine without an intermediate MonadFilter? I don’t know.
@mpilquist @fthomas do you happen to have any thoughts on this?
it may be helpful for me to update my PR so we have something concrete to look at
Denis Rosca
@denisrosca
Jul 20 2016 12:53
@diesalbla @ceedubs Thanks guys, the OptionT thing worked perfectly.
Greg Pfeil
@sellout
Jul 20 2016 14:07
@adelbertc @ceedubs Thanks.
Greg Pfeil
@sellout
Jul 20 2016 14:32
I have a library, tentatively called Griffins, that provides higher-order Functors, etc. – things with shapes like F[_[_], _] – i.e., Free/Cofree/{Co}MonadTransformers, etc.
Haskell libraries tend to call these things HFunctor, HMonad, etc. But Shapeless uses that convention for a different purpose. Wondering if anyone has a naming scheme suggestion.
FunctorK? ;)
But then is a higher-order NaturalTransformation FunctionKK?
Getting close to controversial naming at that point ;)
Greg Pfeil
@sellout
Jul 20 2016 15:20
Implementing things for both Scalaz and Cats is … interesting.
StateT being just a type alias (in Scalaz) is frustrating. Constraints are too tight. E.g., StateT.apply shouldn’t require Monad[F].
Cody Allen
@ceedubs
Jul 20 2016 15:23
@sellout Griffins sounds neat. I don’t have a good naming suggestion though :(. You could split the middle and have FunctorHK :P
and yeah, I imagine supporting both Cats and Scalaz is no fun at all when State is involved
Greg Pfeil
@sellout
Jul 20 2016 15:26
In general, Scalaz wants me to have tighter constraints than I want on my type classes.
Might be worth not having griffins-core, and just defining griffins-cats and griffins-scalaz directly :/
Cody Allen
@ceedubs
Jul 20 2016 15:29
@sellout Is Cats lighter on constraints than Scalaz is in this regard? That kind of surprises me.
Greg Pfeil
@sellout
Jul 20 2016 15:30
@ceedubs Well … on StateT, at least. I haven’t done much more with Cats & Griffins yet. But Scalaz is tighter than MTL, etc. in Haskell.
Cody Allen
@ceedubs
Jul 20 2016 15:33
I think Cats initially had tighter constraints on StateT than Scalaz did (ex: the Monad constrant you mentioned). This was because of the way that we need to lift things into F more often than you’d need to in Haskell so we can trampoline and avoid blowing the stack. I think that Scalaz has since followed suit.
On one of the Cats issues/PRs somewhere @TomasMikula has suggested an alternative way to make StateT stack safe, and I’m interested in pursuing it but haven’t gotten around to it yet