Skip to content

LiftPK: a poly-kinded type lifting operator #10758

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

Closed
OlivierBlanvillain opened this issue Dec 11, 2020 · 2 comments
Closed

LiftPK: a poly-kinded type lifting operator #10758

OlivierBlanvillain opened this issue Dec 11, 2020 · 2 comments

Comments

@OlivierBlanvillain
Copy link
Contributor

As suggested by @abgruszecki in #7389, we should investigate adding a primitive match type to lift * -> *-kinded operators to arbitrary kinds.

Instead of creating special HeadPK and TailPK primitive match types (Head and Tail from Miles' post above), I think it > would be feasible to instead have a LiftPK primitive (lift poly-kinded)
which allows lifting any type operator of kind * -> * to operate on types of arbitrary kinds, and thus allows defining HeadPK and TailPK. The benefit is that LiftPK allows making all type operators poly-kinded, instead of special-casing Head and Tail, and doesn't seem significantly harder to define. It would behave as follows:

type LiftPK[[]] = ... // compiler-provided
type HeadPK[t] = LiftPK[Head][t] // consistent behaviour with Miles' Head
Head[(1,2,3)] === 1
HeadPK[(1,2,3)] === 1
HeadPK[[t] => (t, 2, 3)]] === [t] => t
type TailPK[t] = LiftPK[Tail][t] // similarly, has behaviour consistent with Tail from the preceding post

As for compiler implementation (and probably as a reminer for @OlivierBlanvillain), LiftPK should be implementable by inventing an abstract type for each type parameter, replacing type parameter references with those types, reducing match type (if there's any to be reduced) and undoing the type parameter substitution.

@odersky
Copy link
Contributor

odersky commented Dec 11, 2020

Why is this a bug?

@abgruszecki
Copy link
Contributor

Seconding Martin's remark, this probably shouldn't be a bug.

Another question: should it have the RC1 milestone? It seems that if we don't have this feature or its equivalent by RC1, we will need to release with watered-down Shapeless/typeclass derivation.

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

No branches or pull requests

4 participants