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

Eliminate FunctorT and TraverseT type classes. #51

Merged
merged 3 commits into from
Dec 12, 2016

Conversation

sellout
Copy link
Contributor

@sellout sellout commented Dec 11, 2016

As well as other changes needed in the wake of the directly-recursive
overhaul – like fixing EqualT/ShowT implicits, etc.

As well as other changes needed in the wake of the directly-recursive
overhaul.
@sellout
Copy link
Contributor Author

sellout commented Dec 11, 2016

@paulp This is “in progress” because there may still be a couple changes as I finish updating Quasar to use it, but it should be pretty solid.

(And apologies to @tpolecat for breaking EqualT, etc. for a bit, there)

@paulp
Copy link
Contributor

paulp commented Dec 12, 2016

Looks like a great simplification so far.

@sellout
Copy link
Contributor Author

sellout commented Dec 12, 2016

Yeah, so some comments in that vein …

  1. RecursiveT/Co…T/Bi…T still exist for a few reasons – they make it easy to slowly transition Quasar, they are helpful in faking mutual recursion until that is in, and BirecursiveT works while Birecursive doesn’t, so that’s also nice;
  2. having Birecursive working (Add Birecursive type class #44) would help clean up a bunch of stuff; and
  3. @milessabin’s work on multiple implicit lists will clean up soooo much stuff.

@@ -301,6 +256,185 @@ trait Recursive[T] extends Based[T] {
(implicit R: Corecursive.Aux[R, Base], BF: Functor[Base])
: R =
cata[R](t)(R.embed(_))

def mapR[U, G[_]: Functor]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and below is pulled from FunctorT and TraverseT – it seemed prudent to not get rid of the operations yet (#45 is tracking this), since we use them a bunch in Quasar and I’m just not sure what the right approach is.

There are also some operations moved from earlier in the type class – into the group of things that should be in Birecursive once that is actually usable.

@@ -28,9 +28,9 @@ sealed class IdOps[A](self: A) {
matryoshka.hyloM(self)(f, g)

object ghylo {
def apply[W[_], N[_]] = new Aux[W, N]
def apply[W[_], N[_]] = new PartiallyApplied[W, N]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed these “helper” classes to match the Cats approach, which is named this way to avoid confusion with the other Aux pattern. Figured since I was adding new ones, I should make sure the code is consistent.

This is something that multiple implicit lists would make disappear.

* @group algebras
*/
type AlgebraicTransform[T[_[_]], F[_], G[_]] = F[T[G]] => G[T[G]] // GAlgebraicTransformM[T, Id, Id, F, G]
type AlgebraicGTransform[W[_], T, F[_], G[_]] = F[W[T]] => G[T]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These new aliases just use the new proper type approach. It means the differ a bit (e.g., the types of AlgebraicTransform and CoalgebraicTransform are now the same, so they’re just Transform).

@@ -69,7 +69,7 @@ class PartialSpec extends Specification with ScalazMatchers with ScalaCheck with
"return after multiple runs" >> prop { (a: Conat, b: Conat) =>
val (ai, bi) = (a.cata(height), b.cata(height))
bi > 0 ==> {
val first = (a + b).transAna(Partial.delay(27)).runFor(ai)
val first = (a + b).transAna[Partial[Int]](Partial.delay(27)).runFor(ai)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These operations (like the non-trans operations with the same names) now require a type annotation, because they only know that the result type has a particular functor, but not what proper type that functor has been extracted from.

Different[Mu, Example, Mu[Diff[Mu, Example, ?]]](Empty[Mu[Example]]().embed, NonRec[Mu[Example]]("x", 3).embed).embedT,
Removed[Mu, Example, Mu[Diff[Mu, Example, ?]]](Empty[Mu[Example]]().embed).embedT),
Different[Mu, Example, Mu[Diff[Mu, Example, ?]]](Empty[Mu[Example]]().embed, NonRec[Mu[Example]]("x", 3).embed).embed,
Removed[Mu, Example, Mu[Diff[Mu, Example, ?]]](Empty[Mu[Example]]().embed).embed),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the fixed implicits, we can use the *ecursive ops rather than the *ecursiveT ops, so now we no longer use the T ops, and in fact, no longer have an implicit conversion that makes them available.

@codecov-io
Copy link

Current coverage is 72.67% (diff: 71.18%)

Merging #51 into master will decrease coverage by 0.82%

@@             master        #51   diff @@
==========================================
  Files            38         37     -1   
  Lines           649        666    +17   
  Methods         634        649    +15   
  Messages          0          0          
  Branches         15         17     +2   
==========================================
+ Hits            477        484     +7   
- Misses          172        182    +10   
  Partials          0          0          

Powered by Codecov. Last update 150b572...8cbe2e5

@sellout
Copy link
Contributor Author

sellout commented Dec 12, 2016

Ok, @paulp now it‘s yours.

Once this gets in, I’ll submit the PR that updates Quasar to use this version.

@paulp
Copy link
Contributor

paulp commented Dec 12, 2016

@sellout shouldn't CorecursiveT also lose its @typeclass annotation?

@paulp
Copy link
Contributor

paulp commented Dec 12, 2016

@sellout what about 06e82db, is that okay?

@sellout
Copy link
Contributor Author

sellout commented Dec 12, 2016

Ah yes, that is great :)

@paulp
Copy link
Contributor

paulp commented Dec 12, 2016

I think that's everything concrete I have words for at the moment. Do you want me to make the CorecursiveT change?

@sellout
Copy link
Contributor Author

sellout commented Dec 12, 2016

Sure. I like this new thing in the space between code review and pairing 😄

@paulp
Copy link
Contributor

paulp commented Dec 12, 2016

@sellout I think it's called code repairing

@paulp
Copy link
Contributor

paulp commented Dec 12, 2016

I'll merge it after the tests pass.

@paulp paulp merged commit a2fb5f0 into precog:master Dec 12, 2016
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

Successfully merging this pull request may close these issues.

None yet

3 participants