-
Notifications
You must be signed in to change notification settings - Fork 16
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
⌨️ Add deftype
#381
Comments
Hmm, I don't yet see why |
Consider
This will elaborate to a code, which will then require all of the fields of the |
What I meant was, can I have an example of how your proposed |
Sorry, misunderstood your request! With |
Oh I see. I’m ok with it
… On Jun 24, 2022, at 2:02 PM, Reed Mullanix ***@***.***> wrote:
Sorry, misunderstood your request!
With deftype, we'd elaborate this as a Signature, which should allow us to elaborate the fields as types, which solves the problem.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
Motivation
Currently, the only way to define types is via
def foo : type := ...
, which has some interesting ramifications regarding fibrancy. In particular, we can't define record types with fields of typeI -> A
, and instead have to resort to some weird hacks likeext i => A with []
, which I think we can all agree is suboptimal. We should probably think about adding a way of defining honest-to-god types, rather than only codes.Proposal
The proposed syntax is as follows
The cells would then desugar to a pi type.
We can just inline these during elaboration to avoid having to change the core, but perhaps there's some value in adding these to the core with some unfolding rules.
The text was updated successfully, but these errors were encountered: