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

Some leads on contra-variant subtyping #129

Open
HuStmpHrrr opened this issue Jun 28, 2024 · 3 comments
Open

Some leads on contra-variant subtyping #129

HuStmpHrrr opened this issue Jun 28, 2024 · 3 comments

Comments

@HuStmpHrrr
Copy link
Member

HuStmpHrrr commented Jun 28, 2024

In #127 , I removed contra-variant subtyping because I am not able to justify any termination measure for the subtyping algorithm in #124 . The major issue is that when checking the subtyping relation between return types of Pi, the context becomes smaller for the return type on the left hand side, so the normal form of that type is no longer accurate, c.f. #121 (comment) .

Nevertheless, I still think that contra-variant subtyping should be decidable, and this is the only blocker. As a proof of concept, I have shown in #125 that the subtyping relation in the PER model is transitive, so there really isn't any problem on the semantic side.

After some bangs on the wall, I think we can move forward with the decidability with contra-variant subtyping with the following leads. The main idea is that, the decision of subtyping decreases by the syntax size of normal forms, even if the normal forms are not accurate. Every time we go under Pi's, we re-normalize the return type on the left hand side, but if the size of the normal forms is invariant under subtyping between contexts, then we are good.

Now, the goal is to show that contra-variant subtyping doesn't change the size of normal forms. I think this can be proved, after we finish soundness proof. We need to provide another set of semantic definitions to model this invariant of size. I list a few critical lemmas and definitions below:

  1. First, we should relate two domain values, if their readbacks have equal size. This is what the new semantic definition should eventually imply.
  2. Then, we define an inductive relation between domain values a and b, such that when tagging a a subtype of that of b, then their readbacks have equal size.
  3. We generalize the previous relation to evaluation environments, where the contexts are related by semantic subtyping.
  4. Now we define semantic judgments. For example, for G |- t : T, we should say G is semantically well-formed, and then for all G' a sub-context of G, the evaluations of t in two different environments related by 3 is related by the relation defined in 2.
  5. Instantiate the judgment in 4 will hopefully give us a proof of normal forms having equal size.

It involves some work, probably not gonna be easy, so we should finish what we have now before moving towards this direction. Leave this investigation for the future; if we pull this off, we can write another paper about it.

@Ailrun
Copy link
Member

Ailrun commented Jun 28, 2024

I think we need something really clear, as once we extend the system with contextual types, we have another source of contravariance. Once POPL deadline is over, I will also put an RFC with my idea. (Possibly as a comment in this issue)

@HuStmpHrrr
Copy link
Member Author

I think we need something really clear, as once we extend the system with contextual types, we have another source of contravariance. Once POPL deadline is over, I will also put an RFC with my idea. (Possibly as a comment in this issue)

contextual types might not cause issue. LF is a separate system, it doesn't have to support any subtyping at all.

@Ailrun
Copy link
Member

Ailrun commented Jun 29, 2024

it doesn't have to support any subtyping at all.

Ah yeah, true. But anyway, I think it would be a good idea to have the way as cleanest as possible we can come up with to block as less future extensions as possible.

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

2 participants