- Join over
**1.5M+ people** - Join over
**100K+ communities** - Free
**without limits** - Create
**your own community**

- May 31 02:50Travis typelevel/cats-mtl (djspiewak-feature/rewrite) fixed (703)
- May 31 02:43Travis typelevel/cats-mtl (djspiewak-feature/rewrite) still failing (701)
- May 31 02:41Travis typelevel/cats-mtl#215 broken (702)
- May 31 02:34Travis typelevel/cats-mtl#215 broken (700)
- May 31 02:34Travis typelevel/cats-mtl (djspiewak-feature/rewrite) still failing (699)
- May 31 01:26Travis typelevel/cats-mtl#215 broken (698)
- May 31 01:26Travis typelevel/cats-mtl (djspiewak-feature/rewrite) still failing (697)
- May 31 01:17Travis typelevel/cats-mtl#215 broken (696)
- May 31 01:17Travis typelevel/cats-mtl (djspiewak-feature/rewrite) still failing (695)
- May 15 23:48Travis typelevel/cats-mtl#216 broken (692)
- May 14 23:03Travis typelevel/cats-mtl#215 broken (691)
- May 14 23:02Travis typelevel/cats-mtl (djspiewak-feature/rewrite) still failing (690)
- May 12 19:09Travis typelevel/cats-mtl#209 broken (688)
- May 11 22:59Travis typelevel/cats-mtl (djspiewak-feature/rewrite) still failing (686)
- May 11 22:34Travis typelevel/cats-mtl (djspiewak-feature/rewrite) still failing (685)
- May 11 22:31Travis typelevel/cats-mtl (djspiewak-feature/rewrite) still failing (684)
- Apr 09 00:16Travis typelevel/cats-mtl (djspiewak-feature/rewrite) failed (674)
- Apr 08 19:28Travis typelevel/cats-mtl#209 broken (673)
- Apr 05 23:25Travis typelevel/cats-mtl#208 broken (672)
- Apr 05 23:25Travis typelevel/cats-mtl (covariant-transformers) broken (671)

I'll have to check semantics on that

Hi there!

I'm trying to adapt Discipline's testing approach, but I'm experiencing issues with comparing values in effectful context `F[_]`

like `IO[_]`

.

The source of the problem is in discipline package in cats laws - there is an implicit converter from `IsEq[A]`

to `Prop`

, requiring an `Eq[A]`

and a prettifier `A => Pretty`

.

When `A`

is actually an `IO[A]`

, it means that to use `Pretty`

I have to reevaluate the effects I've already evaluated with `Eq`

or memoize them. I suppose I can come up with my own converter to `Prop`

which runs all effects and remembers their values at the beginning, but maybe I'm missing something and someone here can point me in the right direction.

Hey all, I'm somewhat new to the cats side of Scala and I'm reading through the book "Herding Cats" and under the section regarding partialOrder, it says that

Looking into it, I can see that PartialOrder does indeed implement the comparison operators, but why? There are already comparison operators in the standard library. What's the advantage of using these over the built-in ones?

`PartialOrder also enables >, >=, <, and <= operators, but these are tricky to use because if you’re not careful you could end up using the built-in comparison operators.`

Looking into it, I can see that PartialOrder does indeed implement the comparison operators, but why? There are already comparison operators in the standard library. What's the advantage of using these over the built-in ones?

Here is a link to the page:

`http://eed3si9n.com/herding-cats/PartialOrder.html`

and also what Andi says

`ApplicativeError`

`raiseError[F[_]](e: E)`

given `ApplicativeError[F, E]`

Hmm. I didn’t see any cases of that problem in my usage.

On a related note: if you’re wirting tests and you need an `ApplicativeError`

or `MonadError`

, do you just jump to using `IO`

(or, in my situation, `StateT[IO, MyState, ?]`

because I need `MonadState`

and `MonadError`

)? Or something less powerful than `IO`

? `Try`

?

`Either`

is a pretty easy one
I usually factor typeclass dependencies to be precise for code isolation and semantic information to the reader, rather than so I can actually use non-IO in tests

cats Free is also a bit different in that it factors in

`Coyoneda`

as well, so it's actually closer to `Coyoneda`

in haskell
a good way of looking at it is noting how `Monad`

can be expressed as either (forgetting `Applicative`

)

```
class Functor f => Monad f where
pure :: a -> f a
join :: f (f a) -> f a
```

or

```
class Monad f where
pure :: a -> f a
(>>=) :: f a -> (a -> f b) -> f b
```

.

The first definition gives rise to

```
data Free f a = Pure a | Roll (f (Free f a))
instance Functor f => Monad (Free f) where ...
```

and your algebra looks this way:

```
data Alg a = Put String a | Get String (String -> a)
instance Functor Alg where
```

The second definition, which is `Operational`

(and cats Free) gives rise to

```
data Free f a where
Pure :: a -> Free fa
FlatMap :: f a -> (a -> Free f b) -> Free f b
instance Monad (Free f a) -- note no Functor
```

and your algebra looks this way

```
data Alg a where
Put :: String -> Alg ()
Get :: String -> Alg String
```

and no Functor needed

at first people thought these two were two different things

which is why you don't need to explicitly declare a

`Functor`

for your algebra
```
class Functor f where
fmap :: (a -> b) -> f a -> f b
data Coyoneda f a where
Fmap :: (a -> b) -> f b -> Coyoneda f a
```

in Scala, for a while we were literally doing

`Free[Coyoneda[F, ?], A]`

(with a `FreeC`

type synonym)
until it got folded in, and then it ended up looking like

`Operational`

using

`List`

as the pattern functor
yet another way to look at

`Free`

(especially evident in the first version) is as a tree with a Functorful `f`

of children, and values at the leaves (the `Pure`

constructor is `Leaf a`

, and `Roll`

is the branch, with `f`

children). If you look at `Cofree`

, that's also a Tree with values at the branches instead, and again whose structure is determined by `f`

, and that's a Rose Tree
```
data Free f a = Leaf a | Node f (Free f a)
data Cofree f a = Node a (f (Cofree f a))
```

```
type Rose = Cofree []
-- replace and you get
data Rose a = Node a [Rose a]
```