-
-
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
More flexible TransLift #940
More flexible TransLift #940
Conversation
Er… what? The build is hanging? This change definitely increases the compilation time of |
@djspiewak yeah, this seems to be a big problem at the minute, see the discussion on #938, #810, #942 about fixing this |
@DavidGregory084 Whew! Off the hook. :-) |
* if your transformer does not constrain its lifted effects would | ||
* be `type TC[M[_]] = Unit =:= Unit`. A more common constraint | ||
* might be `type TC[M[_]] = Monad[M]`. | ||
*/ |
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.
Does this doc comment need to be updated to refer to Trivial
?
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.
Yes. Will fix.
In light of the fixed build (#954) this need to be re-merged against the latest master. Sorry about that! |
Current coverage is
|
This looks good to me so far. @djspiewak would you be willing to make that comment update to refer to |
@ceedubs Maybe I'm misreading the coverage report, but as far as I can tell, there's literally nothing to add. All of the testable lines are already tested. The reason the coverage is dropping is I added untestable lines (literally: whitespace and type-level declarations), which for some reason, Codecov includes in the computation which generates the coverage percentage. Again, I may simply be misreading it. If someone can point out to me what I missed, I will happily write tests. :-) |
It looks that way to me as well. 👍 from me! |
Hm given the fancy nature of these types, could you also add some tests in |
Well so much for your 👍! :-) More seriously, the syntax is already tested by what previously existed. I could probably add one or two things that are now supported but which weren't before, but it wouldn't be too different from the tests we already have. |
I was halfway through amending my comment when I saw your new one :-) Yeah I just realized there are pre-existing tests, I wrongly assumed this was a completely new addition. My 👍 stands! |
👍 thanks, @djspiewak! |
Reimplements
TransLift
to no longer fix the type constructor. This is substantially more flexible and makes it possible to achieve the same generality as scalaz'sHoist
. This is done while retaining the flexibility of cats's previous implementation, which is thatliftT
requires the minimal constraint necessary for the targetMT
. In most cases, this isFunctor
, but in some cases (likeKleisli
) it is nothing at all (i.e. no constraint).To handle the "nothing at all" case, I have added a
Trivial
type, which is basically the unit typeclass. It takes no parameters and has a single instance which is guaranteed to be in the implicit scope. Several type aliases are provided to allowTrivial
to be used in slots of varying shapes. AF[_]
typeclass (e.g.Monoid
) can be satisfied byTrivial.P1
, and aF[_[_]]
typeclass (e.g.Monad
) can be satisfied byTrivial.PH1
. I'm very open to nicer naming.Oh, and for students of SI-2712, the way that
TLExtract
is encoded (specifically withSingletonMT
andSingletonM
) demonstrates an interesting workaround to some of its foibles. One concern here is that the error messages will be horrendous. But without control over the typetoString
in@implicitNotFound
, we can't really do better.This PR addresses #917.