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

Remove explicit substitutions #268

Open
HuStmpHrrr opened this issue Dec 7, 2024 · 0 comments
Open

Remove explicit substitutions #268

HuStmpHrrr opened this issue Dec 7, 2024 · 0 comments
Labels
long term Something to think about in a long term

Comments

@HuStmpHrrr
Copy link
Member

HuStmpHrrr commented Dec 7, 2024

Currently, McTT uses explicit substitution calculus, only because Abel's habilitation thesis does so. In the thesis, the motivation of explicit substitutions is to simplify the proof by avoiding reasoning about the relation between substitutions and the evaluation of substitutions. Unfortunately, as we expand features in McTT, explicit substitutions have become an inviable option: explicit substitutions place originally definitional equations into syntactic equivalence, which in addition carries typing information. As a result, reasoning about explicit substitutions will become (or worse, is already) very cumbersome, as we include more and more features.

Therefore, it becomes essential to remove explicit substitutions for this project to work in a longer term.

We can use tools like autosubst to generate substitutions that compute. Now, the only difficulty left is to figure out how the model should work. I think morally, the following relation should hold in the PER model without explicit substitutions:

[[ t [ sigma ] ]] (rho) ~~ [[ t ]] ( [[ sigma ]] (rho) ) in [[ T ]]

for well-typed terms and substitutions. This leads to a change to the definitions of semantic typing for completeness. I think we need to include this condition into the definitions for it to work out. However, I don't have all the details right now. Let's put some thoughts into it and see how it is worked out eventually.

I think a helpful way forward is to experiment with simple types.

@HuStmpHrrr HuStmpHrrr added the long term Something to think about in a long term label Dec 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
long term Something to think about in a long term
Projects
None yet
Development

No branches or pull requests

1 participant