hi~ is there any syntax for working with

`M[Boolean]`

? like regular short circuited logic...
I can see how

`cats.free.Yoneda`

relates to the Yoneda lemma in category theory, but I'm a bit stumped as to how `Coyoneda`

is "the dual view of the Yoneda lemma" -- has anyone got a good link (or quick explanation)?
@mattrussell-sky I find Bartosz's articles hard to beat: https://bartoszmilewski.com/2015/09/01/the-yoneda-lemma/

@doubajam there's

`ifM`

. I think we should add more stuff like `whenM`

/`unlessM`

we have

`whenA`

and `unlessA`

in applicative syntax too, but it's backwards, e.g.`doStuff.whenA(true)`

@gvolpe Definitely a decent resource, but...the "Coyoneda" in Bartosz's article is

`forall x . (x -> a) -> F x`

, but I don't see the connection to `cats.free.Coyoneda`

(https://github.com/typelevel/cats/blob/master/free/src/main/scala/cats/free/Coyoneda.scala), which is more like `(f b, b -> a)`

it doesn't operate on

`M[Boolean]`

, `Applicative`

s can't do that
you need monadic power

ah, sorry, I think I slightly misread what you said :)

@SystemFw will it have some sugar ops looks like (

`&&`

or `||`

)? :smiley:
I'd actually be mildly against it

I think

`(b1, b2).mapN(_ && _)`

is not that bad
Yep, it has to be something along the lines of

`b1.ifM(b2, false.pure[M])`

but I see what you mean now

Hi everyone! I realize the following might be a question for the #scalacheck channel, but I am hoping to see a more fruitful discussion here.

I have a state machine and I'd like to generate random sequences of legal transitions within the machine. How would I do that?

One idea that comes to my mind is to use the

I have a state machine and I'd like to generate random sequences of legal transitions within the machine. How would I do that?

One idea that comes to my mind is to use the

`IndexedStateT[F[_], SA, SB, A]`

data type. With it I could encode legal transitions. However, how do I generate sequences that respect these types in my state machine?
that is, if I have these states and transitions: A -> B, A -> C and B -> C, how do I generate random sequences of transitions A -> C? One would be A -> C and the other one would be A -> B -> C.

There is a

`scalacheck-shapeless`

lib, and also gitter channel. They may be a starting point, for creating tests for generic parameters (essentially what you want is a cartesian product of the states, right?)
@lJoublanc : I guess you can put it that way. Thanks for the pointer!

Also have you looked at the guide? The last bit is on stateful testing: https://github.com/rickynils/scalacheck/blob/master/doc/UserGuide.md#stateful-testing

Hi All, is there a good reason why Functor doesn't have something like

`def transform[A](fa: F[A])(pf: PartialFunction[A,A]): F[A] = map(fa)(a => if (pf.isDefinedAt(a)) pf(a) else a)`

functor has map, and this is sort of like map, but for some values only

`a => if (pf.isDefinedAt(a)) pf(a) else a`

this logic seems completely unrelated to Functor, it's just another thing you are mapping

functor has map, and this is sort of like map, but for some values only

I think this would be the case if `F`

could somehow absorbe an empty value (kinda like `FunctorFilter`

)

but since you are returning a default value, it seems to me that there's nothing specific to functor to it

@tpolecat sure, there are many ways to do it, but it looks ugly and verbose :)

i see that it can be not related to functor, but what about functions like

`def void[A](fa: F[A]): F[Unit] = map(fa)(_ => ())`

in Functor? it looks similar, sort of
as for PF, i guess i had cases where I needed to map over a list of different values and transform only some of those

is it possible if I have a

`EitherT[List, X, Y]`

to get a `EitherT[Future, List[X], List[Y]]`

with some kind of magic function?
@jozic you can always make your function total by adding

`case a => a`

:)
my take: derived functions like

`void`

and `as(x)`

are justified in terms of some vague notion of widespread applicability - this is an important bar to clear b/c otherwise we'd have a million derived functions on every type class. it's also frustrating as there's no good process for determining how widely applicable a suggested combinator is
we use this same philosophy in FS2 -- we try to minimize the size of the API and focus on methods that combine well with each other to build use case specific abstractions

@oleg-py @carymrobbins that's all true, but as I said earlier, it's verbose and ugly

@tpolecat if

what is this line where something is good enough to be added to Functor?

@tpolecat if

`Unit`

is special, then what about `def as[A, B](fa: F[A], b: B): F[B] = map(fa)(_ => b)`

or `def tupleRight[A, B](fa: F[A], b: B): F[(A, B)] = map(fa)(a => (a, b))`

what is this line where something is good enough to be added to Functor?

what is this line where something is good enough to be added to Functor?

@jozic I think another problem there is that all types currently involved in Functor (tuple, unit,

`A`

) are considered pretty unambiguously ok, where `PF`

is not. `PF`

is pretty bad...
also,

`void`

is sort of standard function which comes from Haskell
but notice that Haskell doesn't define

`void`

in the Functor type class
anyway I think @mpilquist 's answer is the most honestly correct

there isn't a set rule

I think we just don't use PF in this style of programming, other than literal PFs in things like

`.collect`

which does end up being kind of nice.
The existing combinators are ones that have proven to be generally useful.

it seems to me that

`void`

is included in `Functor`

for convenience since otherwise it'd have to be just an extension method
in this particular example, another thing going against it is you can easily justify

`def transformE[A,B](fa: F[A])(pf: PartialFunction[A,B]): F[Either[A,B]]`

if you can justify `transform`

it's the pure equivalent of having

`Unit`

inserted in impure code
right, it's convenience

anyway I think @mpilquist 's answer is the most honestly correct

@SystemFw sorry, I don't see an answer from @mpilquist on this question

@jozic for one off things like this, i usually just define my own extension method

```
final implicit class MyFunctorOps[F[_], A](val repr: F[A]) extends AnyVal {
def transform(pf: PartialFunction[A, A])(implicit F: Functor[F]): F[A] = ???
}
```

@carymrobbins i do too, and just wanted to know what people think on it

@SystemFw @mpilquist thanks, makes sense

as for

you can easily justify def transformEA,B(pf: PartialFunction[A,B]): F[Either[A,B]] if you can justify transform

i think what I had is different as it didn't involve additional type like Either

maybe that point was demonstrating that there are a seemingly limitless number of alternatives that could be proposed, and the methods on type classes need to be exclusive to avoid bloat

Sure,

so as I see it, the line is, 1) PFs are not good and 2) we add things for convenience only when they prove to be super useful to keep minimal API

would that be correct summary?

so as I see it, the line is, 1) PFs are not good and 2) we add things for convenience only when they prove to be super useful to keep minimal API

would that be correct summary?

pretty much, but with respect to 2), it's a loose rule, so I'm sure you could find counterexamples. My personal opinion is that that specific code doesn't qualify as common enough

what would the equivalent for

`true.option(List(1)).sequence`

from scalaz?
Indentical if you pull in mouse. The boolean op isn't in cats itself.

They were never part of cats. We decided not to add all those enrichments although I think mouse should just be folded in.

At the time I think people overestimated the size.

@LukaJCB how are implicit function types relevant?

they give you an ambient reader which is just one effect

I can't see how they're useful at all, honestly.

So you could do tagless final with implicit functions

But yeah very loosely :smile:

I guess I'm worried martin will see that tweet and say ok problem solved. Implicit functions do everything.