First stab at a more flexible TransLift

[djspiewak]

This is a review PR only! Please do not merge yet. I have some things I'd like to clean up, but I wanted to get some thoughts.

First off, this is an attempted fix for #917, which is a blocker for emm and shims. It rearranges TransLift so that a single instance is no longer fixed to one inner effect type while keeping the flexibility of not over-constraining said effect. For example, the TransLift instance for Kleisli does not constrain the effect in any way, while the OptionT instance requires a Functor and StateT requires Applicative.

Second off… I think I hit a few compiler bugs (def vs val is apparently significant in implicit resolution?!?!) and also may have made the test compilation time even longer. Sorry…

The magic is in TransLift.scala and transLift.scala (the latter is the syntax class and contains some new implicit machinery) I'm very open to nicer ways of doing this, btw, I just don't want to add a second type parameter to the liftT syntax.

BTW, @stew, does this mean I win the race? ;-P

[adelbertc]

Must resist urge to merge just so it's in before stew even gets a chance to see it.......

[codecov-io]

Current coverage is 88.75%

Merging #918 into master will decrease coverage by -0.03% as of 0f6158b

@@            master    #918   diff @@
======================================
  Files          178     178       
  Stmts         2122    2126     +4
  Branches        42      42       
  Methods          0       0       
======================================
+ Hit           1884    1887     +3
  Partial          0       0       
- Missed         238     239     +1

Review entire Coverage Diff as of 0f6158b

Powered by Codecov. Updated on successful CI builds.

[ceedubs]

That's really bizarre. In what way does it fail if it's a val?

[djspiewak]

It just fails to resolve for some reason. I didn't look at -Xlog-implicits, but it seemed like it was simply not considering the possibility. Passing it explicitly worked fine, and obviously changing it to a def is also fine.

[ceedubs]

I think that this is a more flexible solution than the current implementation. I too would be quite happy to see someone show a cleaner approach, but barring that, I support going forward with something like this.

I'm curious if we could ease the case of lifting a F[_, _] with some helper methods for common cases like Applicative, Functor, and Monad with specialized syntax for those (probably based on Unapply).

[ceedubs]

Anyone else have thoughts on this? @stew @tpolecat?

[stew]

This LGTM. This is essentially the path I had started heading down, but yeah, djspeiwak wins the race :)

[djspiewak]

Alrighty, if the consensus is that this isn't the worst idea in the world, I'll clean it up and push a full PR.

[adelbertc]

👍

[djspiewak]

/me slaps @adelbertc for not using the github reaction feature

^_^

[djspiewak]

Closing this PR so I can open a new one with clear intent to merge…