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

MonadError instance for Kleisli #1543

Merged
merged 1 commit into from
Mar 6, 2017
Merged

MonadError instance for Kleisli #1543

merged 1 commit into from
Mar 6, 2017

Conversation

durban
Copy link
Contributor

@durban durban commented Feb 26, 2017

Fixes #1542.

@codecov-io
Copy link

codecov-io commented Feb 26, 2017

Codecov Report

Merging #1543 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1543      +/-   ##
==========================================
+ Coverage   92.48%   92.48%   +<.01%     
==========================================
  Files         246      246              
  Lines        3885     3886       +1     
  Branches      133      132       -1     
==========================================
+ Hits         3593     3594       +1     
  Misses        292      292
Impacted Files Coverage Δ
core/src/main/scala/cats/data/Kleisli.scala 92.59% <100%> (+0.09%)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ecdd27f...cf7d5c1. Read the comment docs.

@kailuowang
Copy link
Contributor

MonadError is more specific than ApplicativeError and thus should be placed in higher priority, no?

@durban
Copy link
Contributor Author

durban commented Feb 27, 2017

I'm not aware of such a rule (and if there is one, it is already broken by Applicative and MonadReader for Kleisli). Is this documented somewhere? Can it cause any problems having these with a lower priority?

@kailuowang
Copy link
Contributor

@durban, you are right, I believe MonadReader is in the wrong priority according to this rule (mind to fix this on the way as well?). I don't think this rule is documented anywhere here, it's not a cats specific rule, it's more a best practice to my knowledge. My understanding is that this pratice has two benefits:

  1. having an implicit sequence is better not having one.
  2. if you assign the most specific one with the highest priority, it takes less implicit search, so it's slightly more compilation efficient. And sometimes the most specific (and thus powerful) instance is also more performant.
    I might've missed other benefits.


def tailRecM[B, C](b: B)(f: B => Kleisli[F, A, Either[B, C]]): Kleisli[F, A, C] =
Kleisli[F, A, C]({ a => FlatMap[F].tailRecM(b) { f(_).run(a) } })
}
Copy link
Collaborator

@peterneyens peterneyens Mar 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like this we have the same code twice:

  • here in KleisliFlatMap
  • and in catsDataMonadReaderForKleisli

Maybe we could create a KleisliMonad which can be extended by a KleisliMonadReader and a KleisliMonadError (similar as how it is done in StateT) ?

@durban
Copy link
Contributor Author

durban commented Mar 5, 2017

@kailuowang @peterneyens I've amended my commit to address your comments. (I've also rebased to the current master.)

Copy link
Contributor

@kailuowang kailuowang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks very much!

Copy link
Collaborator

@peterneyens peterneyens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Thanks for the changes!

@peterneyens peterneyens merged commit 7e1eabc into typelevel:master Mar 6, 2017
@kailuowang kailuowang modified the milestone: 1.0.0-MF Apr 26, 2017
@durban durban deleted the topic/kleisliMonadError branch August 11, 2017 18:27
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

Successfully merging this pull request may close these issues.

4 participants