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

an example of why it helps if evaluation is type-directed #1

Open
pigworker opened this issue Aug 21, 2020 · 0 comments
Open

an example of why it helps if evaluation is type-directed #1

pigworker opened this issue Aug 21, 2020 · 0 comments
Labels
enhancement New feature or request

Comments

@pigworker
Copy link
Collaborator

We're trying to make more true equations hold definitionally. For example, although thinnings are not unique in general, empty thinnings and endothinnings surely are. Suppose th is variable typed as a thinning from nonempty list of types Nat, Xs to itself. We could select by th from some tuple which starts with 3, then take first projection. With beta rules only, that should get stuck because th is neutral. But if we impose uniqueness of endothinnings, then we must deliver 3, as th is equal to a thinning which retains the head.

So if we want that little bit of eta, we need to be able to tell that th is an endothinning, and that amounts obtaining the type of th, then testing definitional equality of its source and target lists of types. That is, we must ask "is this type the type of the identity thinning?".

Unlike nu-rules, where we replace stuck things by tidier stuck things, this example replaces a stuck thing by 3. Correspondingly, it cannot be delayed until quotation time (i.e., used only when testing definitional equality). This check must be done during evaluation to head normal form. From this we may deduce that we need type information to be present in open evaluation, at least some of the time, which almost certainly means that we need to propagate it everywhere. Moreover, as we need to test definitional equality, we surely need the means to work under binders, which means we should also manage a supply of fresh names (or de Bruijn levels).

Note that the necessity of type information to support computation with open terms does not imply the impossibility of type erasure for execution of closed terms. It's time we stopped treating open computation merely as closed computation with stuff in the way.

@pigworker pigworker added the enhancement New feature or request label Aug 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant