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 Foldable, Traverse and Comonad instances to WriterT #2182

Merged
merged 16 commits into from
Mar 12, 2018
Merged

Add Foldable, Traverse and Comonad instances to WriterT #2182

merged 16 commits into from
Mar 12, 2018

Conversation

barambani
Copy link
Contributor

@barambani barambani commented Mar 4, 2018

This adds Foldable, Traverse and Comonad instances for WriterT. The relevant issue is #620

@codecov-io
Copy link

codecov-io commented Mar 4, 2018

Codecov Report

Merging #2182 into master will decrease coverage by 0.02%.
The diff coverage is 85.71%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2182      +/-   ##
==========================================
- Coverage   94.75%   94.73%   -0.03%     
==========================================
  Files         330      330              
  Lines        5568     5582      +14     
  Branches      201      204       +3     
==========================================
+ Hits         5276     5288      +12     
- Misses        292      294       +2
Impacted Files Coverage Δ
core/src/main/scala/cats/data/WriterT.scala 91.37% <85.71%> (-1.76%) ⬇️
...rc/main/scala/cats/laws/discipline/Arbitrary.scala 100% <0%> (+1.28%) ⬆️

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 9135035...152ee7a. Read the comment docs.

@johnynek
Copy link
Contributor

johnynek commented Mar 4, 2018

I’m surprised this passes binary compatibility, but assuming that’s correct I’m +1

@@ -63,6 +63,17 @@ final case class WriterT[F[_], L, V](run: F[(L, V)]) {
mapWritten(_ => monoidL.empty)

def show(implicit F: Show[F[(L, V)]]): String = F.show(run)

def foldLeft[C](c: C)(f: (C, V) => C)(implicit F: Foldable[F]): C =
F.foldLeft(run, c)((z, v) => f(z, v._2))
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we call v instead lv here to remind us it has the written value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure thing, thanks

F.foldLeft(run, c)((z, v) => f(z, v._2))

def foldRight[C](lc: Eval[C])(f: (V, Eval[C]) => Eval[C])(implicit F: Foldable[F]): Eval[C] =
F.foldRight(run, lc)((v, z) => f(v._2, z))
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we call v as lv here too?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@barambani
Copy link
Contributor Author

@johnynek not sure why it passes, I'm refreshing right now the rules of binary compatibility. What's the change here that you are not 100% sure about ? Because I might work it around even if it passes. Thanks for the help.

@@ -95,9 +106,21 @@ private[data] sealed abstract class WriterTInstances extends WriterTInstances0 {
implicit val F0: Monad[F] = F
implicit val L0: Monoid[L] = L
}

implicit def catsDataFoldableForWriterT[F[_], L, V](implicit F: Foldable[F]): Foldable[WriterT[F, L, ?]] =
Copy link
Contributor

Choose a reason for hiding this comment

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

The Traverse instance is more specific and thus should have a higher priority than the Foldable instance.
In case you are curious, here is the guideline in this regard.
https://typelevel.org/cats/guidelines.html#a-idimplicit-priority-hrefimplicit-prioritya-implicit-instance-priority
I guess you can leave the instance of Traverse where you have now and move the Foldable instance down to WriterTInstance1

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks, makes perfectly sense. I wasn't sure about the precedence there, I should have read the guidelines myself. I'm changing it.

@kailuowang
Copy link
Contributor

I believe the renaming of package private classes is binary compatible. If that's what @johnynek was referring to.

kailuowang
kailuowang previously approved these changes Mar 5, 2018
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.

thanks very much!

@kailuowang kailuowang added this to the 1.1 milestone Mar 5, 2018
@barambani
Copy link
Contributor Author

Thank you lads for helping through the process. 👍

@barambani
Copy link
Contributor Author

Considering that this is still open I would add the Comonad instance to this PR if that's OK

@LukaJCB
Copy link
Member

LukaJCB commented Mar 7, 2018

Sounds good :)

kailuowang
kailuowang previously approved these changes Mar 7, 2018
@kailuowang kailuowang changed the title Issue 620 Add Foldable, Traverse and Comonad instances to WriterT Mar 7, 2018
@kailuowang
Copy link
Contributor

@barambani , I took the liberty to update the PR title, if you don't mind.

@barambani
Copy link
Contributor Author

Thanks for doing it. I will also make the description more accurate

@ceedubs
Copy link
Contributor

ceedubs commented Mar 9, 2018

Can you add resolution tests for Writer (that is, when F is Id)? I suspect that it currently fails to resolve.

@ceedubs
Copy link
Contributor

ceedubs commented Mar 9, 2018

And thanks a lot by the way. This is great!

@barambani
Copy link
Contributor Author

You're right, that's not resolved. I'm adding the tests and the fix. Thanks a lot

@barambani
Copy link
Contributor Author

Just for my understanding, could you point me to some details about why scalac fails to summon F[_] instances for Id ? I know that the de-aliasing is pretty aggressive, so that might be a reason, but I would like to know more. Thanks a lot.

@@ -95,9 +106,23 @@ private[data] sealed abstract class WriterTInstances extends WriterTInstances0 {
implicit val F0: Monad[F] = F
implicit val L0: Monoid[L] = L
}

implicit def catsDataTraverseForWriterTId[L](implicit F: Traverse[Id]): Traverse[WriterT[Id, L, ?]] =
Copy link
Contributor

Choose a reason for hiding this comment

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

@barambani you can't have any instance that potentially conflicts in the same trait level.
I think there is Functor instance conflict here for [WriterT[Id, L, ?]. I think you might need to create quite a few more priority layers to separate the instances.

Copy link
Contributor

Choose a reason for hiding this comment

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

to be clear I didn't see the actually error message on travis. But I think separating them out might solve the problem.

Copy link
Contributor Author

@barambani barambani Mar 9, 2018

Choose a reason for hiding this comment

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

Sorry for the confusion, my bad for the lack of clarity. This prioritisation should work (let's see when the CI completes). My question was more in general about the reason why we needed to create instances for Id. I would have expected that something like Comonad[WriterT[Id, ListWrapper[Int], ?]] could summon the instance for F[_] and I was wondering if you had resources about why that's not the case.
This doesn't mean that I'm not happy to add more priority levels if you think that's better. Thanks for the great help here.

Copy link
Contributor

Choose a reason for hiding this comment

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

@barambani I don't know the underlying reason that Id needs to be special-cased, but it's a weakness in scalac's type inference. This is a related Stack Overflow post that I've seen before. Something like Id might be a tricky one because A =:= Id[A] =:= Id[Id[A]], so there may be some logic to short-circuit inference when applying a type results in the same type so you don't end up in an infinite loop or something. This is pure speculation :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ceedubs thanks a lot, I didn't want for you to waste time on this. I was just taking advantage of this discussion in case you knew it out of your head 😃 👍

ceedubs
ceedubs previously approved these changes Mar 10, 2018
Copy link
Contributor

@ceedubs ceedubs 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 a lot, @barambani!

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 @barambani, I left two small comments.

def foldRight[A, B](fa: WriterT[F, L, A], lb: Eval[B])(f: (A, Eval[B]) => Eval[B]): Eval[B] = fa.foldRight(lb)(f)
}

private[data] sealed trait WriterTTraverse[F[_], L] extends Traverse[WriterT[F, L, ?]] with WriterTFoldable[F, L] {
Copy link
Collaborator

Choose a reason for hiding this comment

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

If you extends WriterTFunctor here as well, you get its map implementation instead of the default traverse[Id] from Traverse.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I will change it thanks 👍


def traverse[G[_], V1](f: V => G[V1])(implicit F: Traverse[F], G: Applicative[G]): G[WriterT[F, L, V1]] =
G.map(
F.traverse(run)(lv => G.product(G.pure(lv._1), f(lv._2)))
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can this be G.tupleLeft(f(lv._2), lv._1) instead of G.product(G.pure(lv._1), f(lv._2))?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sure changing it 👍


override implicit def F0: Traverse[F]

override def map[A, B](fa: WriterT[F, L, A])(f: A => B): WriterT[F, L, B] = super[WriterTFunctor].map(fa)(f)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we can omit this line if we defined map in WriterTFunctor as override def map.

See for example EitherTFunctor and EitherTMonad (although EitherTTraverse doesn't extends EitherTFunctor at the moment and neither does OptionTTraverse OptionTFunctor).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Very true, apologies. I'm fixing it. I rushed it in. I have to stop reading those intellij errors. Do you think I should change also EitherTTraverse and OptionTTraverse accordingly ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think there are probably more cases than just EitherTTraverse and OptionTTraverse which can be improved, I would leave those for another PR.

LukaJCB
LukaJCB previously approved these changes Mar 12, 2018
Copy link
Member

@LukaJCB LukaJCB left a comment

Choose a reason for hiding this comment

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

LGTM :)

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 again @barambani (and for the quick follow up on my nitpicking).

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.

7 participants