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

Switch to an explicitly typed core language #417

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

brendanzab
Copy link
Member

@brendanzab brendanzab commented Nov 10, 2022

This switches the core language to be explicitly typed, which might make compilation easier down the line, for example when figuring out if we need to compile to a term or a type. I remember this was tricky on my last time trying to implementing compilation/extraction, but I’d like to do some more experiments to see if this is actually the case, however, but this at least demonstrates the idea.

The resulting terms are a bit larger than I’d like, because we need to quote type annotations back to terms during elaboration. Glued evaluation potentially help here.

Closes #270

@@ -1,4 +1,4 @@
stdout = '''
fun A a => a : fun (A : Type) -> A -> A
fun (A : Type) (a : a) => a : fun (A : Type) -> A -> A
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a scoping error has been introduced somewhere?
Should be fun (A : Type) (a : A) => a : fun (A : Type) -> A -> A

Copy link
Member Author

@brendanzab brendanzab Nov 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ooooh yes you are right. wouldn't it be great if there was a way to ensure these were well scoped… 😅

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it might be to do with when the function parameter types are quoted but I'll have a look

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was actually an issue in the distiller, which would have been a bit trickier to catch, alas. Perhaps with some sort of roundtrip test maybe.

@Kmeakin
Copy link
Contributor

Kmeakin commented Jan 17, 2023

The resulting terms are a bit larger than I’d like, because we need to quote type annotations back to terms during elaboration. Glued evaluation potentially help here.

Should be fixed by #462? I'd like to see this merged

@brendanzab
Copy link
Member Author

Hmm, not sure. I think most of the bloat added here is from terms that do not come from user code originally. Because they have been quoted from values, they would need something like glued evaluation to keep them small. Does having explicit type annotations help you in something you are looking at? Should we try to get this merged?

@Kmeakin
Copy link
Contributor

Kmeakin commented Jan 17, 2023

Does having explicit type annotations help you in something you are looking at? Should we try to get this merged?

No, I just wanted symmetry with the type annotations in FunType. But if you want to let it cook longer, no pressure

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.

Switch to an explicitly typed core language
2 participants