-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Implement a ReaderWriterStateT data type #1598
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1598 +/- ##
==========================================
+ Coverage 93.33% 93.38% +0.05%
==========================================
Files 240 241 +1
Lines 3946 4053 +107
Branches 142 135 -7
==========================================
+ Hits 3683 3785 +102
- Misses 263 268 +5
Continue to review full report at Codecov.
|
related #1210 |
@iravid, @edmundnoble is working on a new typeclass encoding for better support MTL, #1210 and some discussion here at gitter provide more context. |
Thanks. How should this data type be implemented in light of the new design? Does the new design affect only the typeclass instances or the actual data type as well?
…________________________________
From: Kai(luo) Wang <notifications@github.com>
Sent: Monday, April 10, 2017 6:45:12 PM
To: typelevel/cats
Cc: Itamar Ravid; Mention
Subject: Re: [typelevel/cats] Implement a ReaderWriterStateT data type (#1598)
@iravid<https://github.com/iravid>, @edmundnoble<https://github.com/edmundnoble> is working on a new typeclass encoding for better support MTL, #1210<#1210> and some discussion here at gitter<https://gitter.im/typelevel/cats?at=58e82851408f90be669c7822> provide more context.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1598 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AARSxMyO2ByFm6ikWHP0FTkc3sNv-PH4ks5ruk6IgaJpZM4M30_p>.
|
Just the instances @iravid don't worry, I don't foresee any other changes |
4019c35
to
a88ef45
Compare
@kailuowang can we aim for this to go into 1.0 as well? |
@iravid sure. I only included stuff I liked and/or breaking change. We haven't started the process of surveying what people want for 1.0.0-MF yet (we probably should soon, although I kind of want to figure out the biggest uncertainty - MTL refactor first). |
👍🏻
…________________________________
From: Kai(luo) Wang <notifications@github.com>
Sent: Wednesday, April 12, 2017 4:30:00 PM
To: typelevel/cats
Cc: Itamar Ravid; Mention
Subject: Re: [typelevel/cats] Implement a ReaderWriterStateT data type (#1598)
@iravid<https://github.com/iravid> sure. I only included stuffs I liked and/or breaking change. We haven't started the process of surveying what people want for 1.0.0-MF yet (we probably should soon, although I kind of want to figure out the biggest uncertainty - MTL refactor first).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1598 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AARSxNHzokzUtosl8HVqp0VXHIoktJSmks5rvNHYgaJpZM4M30_p>.
|
@@ -180,3 +180,20 @@ private[cats] sealed abstract class Unapply3Instances { | |||
def subst: F[AA, BB, C] => M[C] = identity | |||
} | |||
} | |||
|
|||
private[cats] sealed abstract class Unapply5Instances { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unapply
machinery is about to be removed #1583 /cc @kailuowang
Yeah, I'll drop that commit after that is merged. Added it temporarily so I could test `traverse` :-)
________________________________
From: wedens <notifications@github.com>
Sent: Wednesday, April 12, 2017 6:18:51 PM
To: typelevel/cats
Cc: Itamar Ravid; Mention
Subject: Re: [typelevel/cats] Implement a ReaderWriterStateT data type (#1598)
@wedens commented on this pull request.
________________________________
In core/src/main/scala/cats/Unapply.scala<#1598 (comment)>:
@@ -180,3 +180,20 @@ private[cats] sealed abstract class Unapply3Instances {
def subst: F[AA, BB, C] => M[C] = identity
}
}
+
+private[cats] sealed abstract class Unapply5Instances {
Unapply machinery is about to be removed #1583<#1583> /cc @kailuowang<https://github.com/kailuowang>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1598 (review)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AARSxJn6FUT7HZzN2DRmG0ibA76YHPJiks5rvOtbgaJpZM4M30_p>.
|
This is now ready for review. |
c205e5a
to
8601f42
Compare
Any chance this could get reviewed? |
@iravid I haven't looked at this yet, but I am curious if this better resides in the new cats-mtl/transmogrify. see #1616 cc @edmundnoble |
Happy to move it there, but as this is a concrete data type it seems to me to be better suited to `cats.data`.
|
I agree that cats-mtl/transmogrifier should be for typeclasses, not for specific data structures. |
035fab0
to
3a27f48
Compare
Rebased and removed Unapply instance that was added |
I can only speak for myself - I found a need for it in a recent project, in which I would've used it as a data type without MTL :-)
…________________________________
From: Kai(luo) Wang <notifications@github.com>
Sent: Friday, April 21, 2017 6:16:07 PM
To: typelevel/cats
Cc: Itamar Ravid; Mention
Subject: Re: [typelevel/cats] Implement a ReaderWriterStateT data type (#1598)
@iravid<https://github.com/iravid> @wedens<https://github.com/wedens> my secret agenda is more about keeping cats.core lean. This data type is clearly useful, I am curious is it more useful with MTL typeclasses (I never used it for real)? Obviously if it's commonly used without MTL typeclasses it makes sense for it to stay here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1598 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AARSxFLxZxQ6oth4B2_886pNioOpsOuPks5ryMg3gaJpZM4M30_p>.
|
Ping :-) Can we push this forwards? |
@iravid, not sure if you noticed, build on scala 2.10.6 is broken |
Thanks! |
Looks green, fortunately :-) |
@iravid first of all thanks a lot for being patient with us and this big contribution. Right now we have quite a PR backlog. I am not familiar with the subject enough to review this (although if you want, adding some documentation to the datatypes section on the website might help, e.g. use cases, examples, paper reference etc.). If you'd like to accelerate the review process, mentioning it on gitter might help. |
Sure, I'll try asking for a review on gitter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After a first pass, this looks good. Since it's so large, I'll do another tomorrow.
implicit def L: Monoid[L] | ||
type TC[F[_]] = Applicative[F] | ||
|
||
def liftT[F[_], A](fa: F[A])(implicit F: Applicative[F]): RWST[F, E, S, L, A] = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just duplicated from RWST.lift
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right! Will delegate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only possible things I can think of are tests that ask >> ask
has the same result as ask
, or the reader law, and that local
actually modifies the context
. Otherwise very well done, and great coverage.
Thanks @edmundnoble. I'll add those additional tests and the Reader law and ping you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iravid The tests I mentioned are actually MonadReader laws, which you test already. LGTM.
Good point ;) Been a while since I looked at the code. Thanks! @kailuowang I assume we need another 👍 to merge, right? |
@iravid hmm, for a PR as large as this, we could use more pairs of eyeballs.
|
Sure - the more, the merrier ;)
… On 10 May 2017, at 14:19, Kai(luo) Wang ***@***.***> wrote:
@iravid <https://github.com/iravid> hmm, for a PR as large as this, we could use more pairs of eyeballs.
We are currently following a practice of requiring at least two sign-offs to merge PRs (and for large or contentious issues we may wait for more).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1598 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARSxKwtgf1u30sieojC9o8sNALI7UlNks5r4Z1CgaJpZM4M30_p>.
|
* In other words, it is a pre-baked stack of `[[ReaderT]][F, E, A]`, `[[WriterT]][F, L, A]` | ||
* and `[[StateT]][F, S, A]`. | ||
*/ | ||
final class RWST[F[_], E, S, L, A](val runF: F[(E, S) => F[(L, S, A)]]) extends Serializable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better to have ReaderWriterStateT
be the canonical name, with RWST
as an alias? I look at this as being similar to FunctionK
and ~>
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed
* Combine this computation with `rwsb` using `fn`. The state will be be threaded | ||
* through the computations and the log values will be combined. | ||
*/ | ||
def map2[B, Z](rwsb: RWST[F, E, S, L, B])(fn: (A, B) => Z)(implicit F: FlatMap[F], L: Semigroup[L]): RWST[F, E, S, L, Z] = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there an advantage to having this as a separate implementation, rather than just straight delegating to flatMap
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that's an excellent point.
import cats.syntax.either._ | ||
|
||
/** | ||
* Represents a stateful computation in a context `F[_]`, over state `S`, with an initial environment `E`, an accumulated log `L` and a result `A`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor thing, but I believe in cats the convention is javadoc-style doc comments, rather than scaladoc-style. Thusly:
/**
* Docs here
*/
Rather than
/**
* Boo
*/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Addressed @djspiewak's comments |
Wow @iravid this is fantastic. Sorry for letting this hang for quite a while. The only change that I could think of was potentially changing |
/** | ||
* Get the input state, without modifying it. | ||
*/ | ||
def get(implicit F: Functor[F]): ReaderWriterStateT[F, E, S, L, S] = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The corresponding method in State
is named get
, but for RWST I wonder if getS
(or perhaps getState
) might be a better name. In particular, this will help distinguish between getting the input E
and getting the input S
.
/** | ||
* Return the input state without modifying it. | ||
*/ | ||
def get[F[_], E, S, L](implicit F: Applicative[F], L: Monoid[L]): ReaderWriterStateT[F, E, S, L, S] = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Along the lines of my other comment, I wonder if this should be getS
.
/** | ||
* Return the input state without modifying it. | ||
*/ | ||
def get[E, S, L: Monoid]: ReaderWriterState[E, S, L, S] = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as others :)
@djspiewak @kailuowang could you please take another look now that I think all review suggestions have been addressed? |
@ceedubs In my original review, the only thoughts/reservations I had were expressed, and have now been fixed. So I'm 👍 now. |
One thing that should be changed is switching the |
@iravid No need to worry about that :) |
Resolves #1597.
Still missing:
I'd love to get some feedback on the structure; this is mostly just a re-implementation of methods from StateT, WriterT and ReaderT, which was great for understanding how everything is wired up and is probably more efficient, but I do wonder about the maintainability of this approach.