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

Add documentation for type class derivation #7063

Merged

Conversation

@milessabin
Copy link
Contributor

commented Aug 18, 2019

Needs elaboration, but it's up to date, and the running example is reasonably simple given that it's low-level, and works as expected.

@milessabin

This comment has been minimized.

Copy link
Contributor Author

commented Aug 20, 2019

I'll merge this when it goes green unless anyone has any objections.

@milessabin milessabin merged commit 1f22a40 into lampepfl:master Aug 20, 2019

2 checks passed

CLA User signed CLA
Details
continuous-integration/drone/pr Build is passing
Details

@milessabin milessabin deleted the milessabin:topic/type-class-derivation-docs branch Aug 20, 2019

type MirroredType
/** the type of the elements of the mirrored type */
type MirroedElemTypes

This comment has been minimized.

Copy link
@julienrf

julienrf Aug 20, 2019

Suggested change
type MirroedElemTypes
type MirroredElemTypes
def fromProduct(p: scala.Product): MirroredMonoType
}
trait Sum extends Mirror { self =>

This comment has been minimized.

Copy link
@julienrf

julienrf Aug 20, 2019

Suggested change
trait Sum extends Mirror { self =>
trait Sum extends Mirror {
// Mirror for Tree
Mirror.Sum {
type MirroredType = Tree
type MirroredElemTypes[T] = (Branch[T], Leaf[T])

This comment has been minimized.

Copy link
@julienrf

julienrf Aug 20, 2019

I’m confused that MirroredElemTypes now takes a type parameter, even though in the definition of Mirror it is *-kinded. Is this valid?

This comment has been minimized.

Copy link
@milessabin

milessabin Aug 20, 2019

Author Contributor

MirroredElemTypes is defined in subtypes of Mirror where the appropriate kind is known. The definition I showed as a member of Mirror is illustrative rather than actual ... I guess I should at least mention this at that point, but I didn't want to complicate things. One option would be to define these types in Mirror with an AnyKind bound ... do you think that would be preferable to deferring the definitions?

This comment has been minimized.

Copy link
@julienrf

julienrf Aug 20, 2019

One option would be to define these types in Mirror with an AnyKind bound ... do you think that would be preferable to deferring the definitions?

Maybe it’s not needed. Your explanation made it clear. We can probably just add somewhere that the shown Mirror definition is not the actual one, but a simplified version.

### Mirrors
with the instances for children in hand the `derived` method uses an `inline match` to dispatch to methods which can
construct instances for either sums or products (2). Note that because `derived` is `inline` the match will be
resolved at compile-time and only the left-hand side of the matching case will be inlined into the generated code with

This comment has been minimized.

Copy link
@julienrf

julienrf Aug 20, 2019

Suggested change
resolved at compile-time and only the left-hand side of the matching case will be inlined into the generated code with
resolved at compile-time and only the right-hand side of the matching case will be inlined into the generated code with

@anatoliykmetyuk anatoliykmetyuk added this to the 0.18 Tech Preview milestone Aug 28, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.