Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Addition derived combinators for Monad, Appliicative #823

Closed
lukewyman opened this issue Jan 22, 2016 · 6 comments
Closed

Addition derived combinators for Monad, Appliicative #823

lukewyman opened this issue Jan 22, 2016 · 6 comments

Comments

@lukewyman
Copy link
Contributor

Do we want to have any/all of the following derived combinators for cats structures such as Monad and Applicative?

def compose[A,B,C](f: A => F[B], g: B => F[C]): A => F[C]
def replicateM[A](n: Int, fa: F[A]): F[List[A]]
def filterM[A](as: List[A])(f: A => F[Boolean]): F[List[A]]
@adelbertc
Copy link
Contributor

compose I think is handled by the Kleisli data type

filterM we have via MonadCombine

replicateA would be useful to have, i'm guessing on Applicative (maybe Traverse)

def replicateA[F[_] : Applicative, A](n: Int, fa: F[A]): F[List[A]] =
  List.fill(n)(fa).sequence

@lukewyman
Copy link
Contributor Author

I took a shot at adding replicateA, as noted above, and immediately ran into the following compiler error:

/cats/Applicative.scala:35: could not find implicit value for evidence parameter of type cats.Traverse[List]

Since sequence is dependent on what type of collection the Traverse instance is for, it won't work on a concrete type like List

Is there another way I should try and implement this, or am I being naive in wanting to add this combinator?

@ceedubs
Copy link
Contributor

ceedubs commented Jan 28, 2016

@lukewyman I think import cats.std.list._ should make that compiler error go away.

@lukewyman
Copy link
Contributor Author

...and indeed, it did. Thanks, @ceedubs.

ceedubs added a commit that referenced this issue Mar 4, 2016
@mikejcurry
Copy link
Contributor

Should this one be closed now that #830 has been merged - or am I wrong and is there something left on it?

@ceedubs
Copy link
Contributor

ceedubs commented Jun 18, 2016

It sounds like all of these are taken care of except for filterM, which is being tracked by #1054, so I'm going to go ahead and close this out. Feel free to reopen if I've missed something.

@ceedubs ceedubs closed this as completed Jun 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants