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

feat: type-level let #684

Merged
merged 7 commits into from
Sep 13, 2022
Merged

feat: type-level let #684

merged 7 commits into from
Sep 13, 2022

Conversation

brprice
Copy link
Contributor

@brprice brprice commented Sep 6, 2022

Support lets in types to the same extent as typelet in terms. Use them when doing a BETA reduction (in EvalFull).

@brprice brprice added the WIP A work in progress, not ready for merging label Sep 6, 2022
@brprice brprice force-pushed the brprice/let-type branch 3 times, most recently from 6b8c8c7 to 6bc3080 Compare September 12, 2022 13:19
@brprice brprice marked this pull request as ready for review September 12, 2022 13:20
@brprice
Copy link
Contributor Author

brprice commented Sep 12, 2022

This unblocks #559

@brprice brprice removed the WIP A work in progress, not ready for merging label Sep 12, 2022
@brprice brprice requested a review from a team September 12, 2022 13:21
@brprice brprice changed the title WIP: let type feat: type-level let Sep 12, 2022
@dhess
Copy link
Member

dhess commented Sep 12, 2022

Just so I understand, this is so we can represent substitution of type lambdas during eval as let bindings, analogous to how we represent substitution of term lambdas as lets , correct?

@brprice
Copy link
Contributor Author

brprice commented Sep 12, 2022

Just so I understand, this is so we can represent substitution of type lambdas during eval as let bindings, analogous to how we represent substitution of term lambdas as lets , correct?

s/type lambdas/forall types/ and I'd agree. Another thing this lets (hah!) us do is "pushing down let bindings" #44, which previously would have to stop at a type (i.e. annotation or type application)

Similarly to 'lettype', these will be unsupported in the typechecker. It
is expected that (for now) they are only ephemeral nodes used during
evaluation. However, this commit does not implement support in the
evaluators or generators. (It does implement support everywhere other
than the typechecker, the evaluators and the generators.)
We also draft support for type-level lets in the typed generator.
However, this is commented out because the typechecker does not support
lets in types.
Note that this only handles lets that somehow already appear in types --
we do not create them. (In fact, because Eval drops the relevent
annotations (in BETA redexes), we don't have any place we want to use
such lets).
Note that this only handles lets that somehow already appear in types --
we do not create them.
@brprice brprice added this pull request to the merge queue Sep 13, 2022
Merged via the queue into main with commit 678cd44 Sep 13, 2022
@brprice brprice deleted the brprice/let-type branch September 13, 2022 11:59
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

Successfully merging this pull request may close these issues.

3 participants