-
-
Notifications
You must be signed in to change notification settings - Fork 178
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
Standardize records of mixed kinds #689
Conversation
This currently contains the changes to tests as a result of the changes in dhall-lang/dhall-haskell#1173. Before I write the prose according to this, could I get a sanity check that these tests changes look good? |
LGTM so far. I'm missing a few tests though:
|
Done
There is { foo = 1 } ∧ { bar = Text } : { foo : Natural, bar : Type } Do you have something else in mind?
Done |
That's a test for |
🤦♂️ Thanks |
How about |
Cheers! :) I noticed this though:
It seems unrelated, but shouldn't it be allowed? |
I think there might be some kind of bug with the
I have no idea what's going on there! I think when |
Yeah, it's confusing and should be fixed. I seem to remember that the repl keeps a history, and tries to typecheck previous results, which doesn't always work. |
Yea, that seems to be an existing bug - I've reported dhall-lang/dhall-haskell#1193 as a minimal repro (which happens regardless of my work). With regards to your comment, that is permitted. If you have a fresh REPL session:
As expected. |
How do people feel about 59aa4ee as a first stab? I need to define what the ⋁ judgement is, but that's trivial. Alternatively, rather than mentioning how to cons a |
Looks pretty good to me so far! I believe the judgments for the operations (selection, projection, merges, possibly |
Oh sure, plenty more work - just taking it one step at a time. |
That would be nice. I think we'd need something like a |
I believe that
is now redundant, since it's a special case of
when |
That, or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great so far!
Ok, I've now added |
Ok, I've tried to update the record merge type inference rules too. |
standard/type-inference.md
Outdated
|
||
|
||
Γ ⊢ l :⇥ { ls… } | ||
{ ls… } :⇥ Type | ||
{ ls… } :⇥ t |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do I need to say t \elem { Type, Kind, Sort }
? This comment applies to various other places where I've replaced Type
with a metavariable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here you don't, because a record type can only have type Type
, Kind
or Sort
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thank you for doing this 🙂
One thing we should do (which can be a follow-up change) is to update the Prelude to take advantage of this
Yea, I think the Prelude is a separate PR. I like to keep changes in PRs be "required to change" rather than "could now be changed". |
To clarify, do I need to wait 3 days now? Or does mergify take care of waiting for 3 days? If we have to wait, I'll just merge on Monday. |
My interpretation is that a PR should be merged no earlier than 3 days after the last change to the patch.
Mergify is only enabled for the |
@ocharles: The full rules are here: This repository is not Mergify-enabled, so you just have to know how long to wait according to those rules. We don't have clear rules around when the "clock" begins for draft pull requests. My rough rule is to reset the clock after each change, meaning:
Given that we only have one approval so far, we should wait up to 7 days to give the other two approvers a chance to comment. If they don't comment then it's an implicit approval and then you can merge. If they both approve then you can merge after just a 3-day wait. |
Super, thanks for the info. |
I've created a new label "Voting Open" just to indicate that the author deems the work finished and is now looking for votes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a few inline comments.
Also: Can you check the rules for field selection? I believe they can be relaxed. If so, please add tests for them.
And does your branch for dhall-haskell
already pass all the acceptance tests?
|
||
|
||
... where `t₀` and `t₁` are either `Type`, `Kind`, or `Sort` (though they may | ||
differ). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
though they may differ
Should that mean that t₀
and t₁
don't have to be the same?
Would
... where
t₀
andt₁
each are eitherType
,Kind
, orSort
.
be clearer?!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to emphasize that t₀ = Type
and t₁ = Sort
is valid. I may have made things more confusing, but I don't have a better suggestion. I'm open to changes here, if anyone wants to suggest anything! Happen to use your wording @sjakobi if it's clearer.
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for doing this! 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great from an admittedly superficial skim. I spotted a minor presentation fix but nothing else.
Co-Authored-By: Philip Potter <philip.g.potter@gmail.com>
@sjakobi dhall-lang/dhall-haskell#1173 passes all the tests added here, but fails due to some unrelated changes. Am I good to merge this PR (the standard change)? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cheers! Sorry for the delay!
And we're done! Thanks for the help, all! |
... as standardized in dhall-lang/dhall-lang#689
No description provided.