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

Restore support for records containing both types and terms #1173

Merged
merged 27 commits into from
Aug 31, 2019

Conversation

ocharles
Copy link
Member

@ocharles ocharles commented Jul 30, 2019

... as standardized in dhall-lang/dhall-lang#689

@ocharles ocharles added the wip Work in progress - the author is not yet asking for reviews label Jul 30, 2019
@sjakobi
Copy link
Collaborator

sjakobi commented Jul 30, 2019

This makes sense to me so far – but I don't know much about these things.

I think you should probably also adjust the typechecking for /\, // (and probably //\\ too?). In both cases we currently check that the two records have the same kind, which I assume we don't want to check anymore. That would allow something like

{ a = 0 } // { a = Bool }

@ocharles
Copy link
Member Author

Thanks @sjakobi - I wasn't sure if that was explicitly checked in the type checker. I'll have a look and update that.

Copy link
Collaborator

@Gabriella439 Gabriella439 left a comment

Choose a reason for hiding this comment

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

This looks good so far, just one comment

dhall/src/Dhall/TypeCheck.hs Show resolved Hide resolved
@ocharles
Copy link
Member Author

This is getting there, but I'm stuck on what to do with one test case. The test input is:

{ x = Type, y = Kind }

Which does have a type - it has type

{ x : Kind, y : Sort }

However, the current test harness can't actually verify this, because the expected type is itself type checked, and { x : Kind, y : Sort } does not have a type (because Sort doesn't have a type).

Should I reject RecordLits that contain Kinds?

@Gabriella439
Copy link
Collaborator

Gabriella439 commented Jul 31, 2019

@ocharles: Yes, I believe you would need to reject records that contain fields set to Kind. This is actually not a consequence of the test harness limitations but rather a consequence of the rule that record literal's inferred type must itself type-check, and a record type with a Sort in it is not valid.

@ocharles
Copy link
Member Author

Thanks for the clarification - I'll see what I can do.

@MonoidMusician
Copy link
Contributor

Nice! Did you see this issue: dhall-lang/dhall-lang#558 ? It might be nice to put it in with this change, but we can always take care of it in a separate PR too – up to you.

@ocharles ocharles removed the wip Work in progress - the author is not yet asking for reviews label Aug 9, 2019
@ocharles ocharles changed the title Restore support for records containing both types and terms (WIP) Restore support for records containing both types and terms Aug 9, 2019
Copy link
Collaborator

@sjakobi sjakobi left a comment

Choose a reason for hiding this comment

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

Can you make sure the full acceptance testsuite passes, before you merge dhall-lang/dhall-lang#689?

dhall/src/Dhall/TypeCheck.hs Show resolved Hide resolved

kts <- Dhall.Map.unorderedTraverseWithKey process kvs'
_ <- loop ctx recordType
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why is this check necessary? If it is necessary, do we have a test for it?

Copy link
Collaborator

Choose a reason for hiding this comment

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

It's required by the standard, but it might be redundant now that we permit mixed records. In other words, this additional check required by the standard might not actually catch anything that the other checks do so there wouldn't be a differentiating test, but the standard would need to be fixed.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Either way I'll remove it as I'm reasonably sure it's no longer necessary and the standard change can follow

dhall/src/Dhall/TypeCheck.hs Show resolved Hide resolved
@@ -546,19 +527,15 @@ typeWithA tpa = loop
_ -> Left (TypeError ctx e (MustCombineARecord '∧' kvsY tKvsY))

ttKvsX <- fmap Dhall.Core.normalize (loop ctx tKvsX)
constX <- case ttKvsX of
_ <- case ttKvsX of
Const constX -> return constX
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just return ().

Copy link
Collaborator

Choose a reason for hiding this comment

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

Or is this check necessary at all?

Copy link
Collaborator

Choose a reason for hiding this comment

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

It is not necessary any longer, so I'll remove it. One invariant of the type system is that the type of the type of something will always be a type-checking constant (i.e. Const) so if we don't care about the specific constant then we no longer need to check this

Const constX -> return constX
_ -> Left (TypeError ctx e (MustCombineARecord '∧' kvsX tKvsX))

ttKvsY <- fmap Dhall.Core.normalize (loop ctx tKvsY)
constY <- case ttKvsY of
_ <- case ttKvsY of
Const constY -> return constY
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same here.

dhall/src/Dhall/TypeCheck.hs Show resolved Hide resolved
@@ -621,19 +590,15 @@ typeWithA tpa = loop
_ -> Left (TypeError ctx e (MustCombineARecord '⫽' kvsY tKvsY))

ttKvsX <- fmap Dhall.Core.normalize (loop ctx tKvsX)
constX <- case ttKvsX of
_ <- case ttKvsX of
Const constX -> return constX
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same comments as for Combine.

@Gabriella439
Copy link
Collaborator

@ocharles: I opened a pull request against your branch to fix the test failure and address the review feedback: circuithub#1

Address review feedback for mixed records pull request
@ocharles
Copy link
Member Author

ocharles commented Aug 31, 2019 via email

@Gabriella439 Gabriella439 merged commit 2877525 into dhall-lang:master Aug 31, 2019
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.

None yet

4 participants