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

TransLift expressiveness is limited #917

Closed
djspiewak opened this issue Mar 5, 2016 · 6 comments
Closed

TransLift expressiveness is limited #917

djspiewak opened this issue Mar 5, 2016 · 6 comments

Comments

@djspiewak
Copy link
Member

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's Hoist, and I'm fairly certain even TransLift 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:

trait TransLift[MT[_[_], _]] {
  type TC[M[_]]
  def liftT[M[_], A](ma: M[A])(implicit M: TC[M]): MT[M,A]
}

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.

@ceedubs
Copy link
Contributor

ceedubs commented Mar 5, 2016

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 liftT (like Kleisli), I think you are forced to write a dummy typeclass for which there is a trivial implicit instance.

@djspiewak
Copy link
Member Author

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 liftT (like Kleisli), I think you are forced to write a dummy typeclass for which there is a trivial implicit instance.

You can do that, or you can cheat with something ugly like I did and set the typeclass to Lambda[X[_] => Unit =:= Unit], which will obviously trivially resolve.

@adelbertc
Copy link
Contributor

set the typeclass to Lambda[X[_] => Unit =:= Unit]

inches away

@ceedubs
Copy link
Contributor

ceedubs commented Mar 8, 2016

@djspiewak clever. I like it.

@adelbertc
Copy link
Contributor

@djspiewak can we call this closed?

@djspiewak
Copy link
Member Author

Yep

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants