-
-
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
TransLift expressiveness is limited #917
Comments
I started working on cleaning up my stash of this approach that I had. I remembered that a strange thing about the proposed change is that for types that don't require any constraint to |
You can do that, or you can cheat with something ugly like I did and set the typeclass to |
inches away |
@djspiewak clever. I like it. |
@djspiewak can we call this closed? |
Yep |
As discussed with @stew, capturing the type constructor to be lifted in the enclosing typeclass is neat in that it does allow the constraint to vary, but it also causes some problems at the call site. It also unfortunately makes it impossible for cases like shims, since I cannot abstract over both
TransLift
and scalaz'sHoist
, and I'm fairly certain evenTransLift
alone would not be usable for emm.As a sidebar, I suspect that the insertion of the type constructor into the typeclass also gives rise to problems related to SI-2712 for users writing functions polymorphic in that effect type; problems which wouldn't occur with the type attached to
liftM
.We proposed adjusting the type of
TransLift
to something more like the following signature:This would retain the power of the variable constraint by binding that power to the transformer itself, not the pair of the transformer and the inner effect. @ceedubs noted that he had tried this approach in the past and ran into some problems with
Unapply
cases, but I think it's worth exploring a bit further.The text was updated successfully, but these errors were encountered: