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

Add Applicative for Arrow #2078

Merged
merged 4 commits into from
Dec 10, 2017

Conversation

stephen-lazaro
Copy link
Contributor

@stephen-lazaro stephen-lazaro commented Dec 7, 2017

Adds an Apply instance as discussed in #2069
It can be weakened to Semigroupal if we don't buy the Apply.
Currently, it is implicit. There was discussion in the issue on whether it should be explicit or implicit. Either answer seems reasonable so I wrote the doctest to be compatible with either way people end up preferring.
Do we need additional tests over the doctest?

@codecov-io
Copy link

codecov-io commented Dec 7, 2017

Codecov Report

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

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2078      +/-   ##
==========================================
+ Coverage   94.66%   94.67%   +<.01%     
==========================================
  Files         318      318              
  Lines        5383     5388       +5     
  Branches      207      216       +9     
==========================================
+ Hits         5096     5101       +5     
  Misses        287      287
Impacted Files Coverage Δ
core/src/main/scala/cats/Applicative.scala 88.23% <100%> (+4.9%) ⬆️
core/src/main/scala/cats/SemigroupK.scala 100% <0%> (ø) ⬆️
core/src/main/scala/cats/MonoidK.scala 80% <0%> (ø) ⬆️

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 084b984...8cfc67e. Read the comment docs.

@kailuowang
Copy link
Contributor

kailuowang commented Dec 7, 2017

This is cool. I start to think Applicative is also possible right?

def pure[B](b: B): F[A, B] = lift(_ => b) 

Also we should probably move it to Applicative companion object, having them in Arrow companion won't make it available for implicit search.
And I propose we add additional tests with a new type of Function1 and an Arrow instance for it and then test the Applicative laws

* res0: (Long, Int) = (3,6)
* }}}
*/
implicit def catsSemigroupalForArrow[F[_, _], A](implicit F: Arrow[F]): Semigroupal[F[A, ?]] = new Apply[F[A, ?]] {
Copy link
Contributor

Choose a reason for hiding this comment

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

it's probably worthwhile to override product.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, will do.

@stephen-lazaro
Copy link
Contributor Author

You're totally right, that seems to work. We'll have to check the laws but just from intuition it seems right. I have heard Arrow is Category + Applicative so maybe we're now figuring out the Applicative part ;)
Will do on the moving and adding the tests. 👍

@julienrf
Copy link
Contributor

julienrf commented Dec 7, 2017

In case you don’t know this paper, I think it’s a good read about the relationship between arrows and applicatives: http://homepages.inf.ed.ac.uk/slindley/papers/idioms-arrows-monads.pdf

@stephen-lazaro stephen-lazaro changed the title Add Apply for Arrow Add Applicative for Arrow Dec 8, 2017
@stephen-lazaro
Copy link
Contributor Author

stephen-lazaro commented Dec 8, 2017

Cool. Strengthened the instance to Applicative and added it to the Applicative companion object. Also added a test for a function type (let me know if I misunderstood the suggestion there and you'd prefer a stronger test). I didn't see any binary compat issues locally.

* scala> g(5)
* res0: String = hello
* }}}
*/
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for writing these doctests. But doctests in an instance are probably not necessary. They won't be included in apidoc, and these methods are already thoroughly tested in law tests of the instance. So, although the more tests the better, having them here has two slight cons, a) more code to read, in an instance definition, people want to quickly see how the instance is the implemented, rather than the API usage. and b) they provide redundant test coverage for these implementations, so if somehow the instance is not test by law tests, the test coverage report won't expose that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, yeah, that makes sense.

@kailuowang kailuowang merged commit b0cf5c0 into typelevel:master Dec 10, 2017
@kailuowang kailuowang added this to the 1.0.0 milestone Dec 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants