unify Combine and CombineTypes

[winitzki]

Allow the /\ operator to work on record types, exactly as in the functionality of //\\.

This PR follows up on discussions elsewhere:

dhall-lang/dhall-lang#1079 (comment)
dhall-lang/dhall-lang#1378 (comment)

This is a change that keeps all type-correct programs still type-correct but adds new correct programs.

Examples:

⊢ { a : Bool } ∧ { b : Bool }

{ a : Bool, b : Bool }

⊢ { a = { b : Natural}, a = { c : Natural } }

{ a = { b : Natural, c : Natural } }

⊢ { a : { b : Bool } } ∧ { a : { c : Bool } }

{ a : { b : Bool, c : Bool } }

None of these expressions would be type-checked by the old Dhall code because the operator ∧ was not supposed to work on record types (only on record values). However, there seems to be no good reason to have two different operators for merging record values and for merging record types.

Recent discussions move towards making Dhall have similar facilities for record values and record types. As long as there is no ambiguity between them, we can keep the same operators (dot, //, with) to work with both record values and record types.

• The Combine operation (/\) should work on record types just like the CombineTypes operation (//\\)
• Typechecking must work
• Beta-normalization must work
• New regression tests (not sure how to organize that without breaking things)

Any comments welcome; I am fairly new to this code base and to Haskell.

Open questions:

• Currently the /\ operator is inserted automatically when a record has duplicate fields. For example, { a = { x = 1 }, a = { y = 2 } } is translated into { a = { x = 1 } /\ { y = 2 } } at parsing stage and then reduced to { a = { x = 1, y = 2 } } at evaluation stage. Do we want the same behavior for record types? At the moment, { a : { x : Natural }, a : { y : Bool } } is a type error ("duplicate field: a"). Is there any reason not to rewrite this as { a : { x : Natural } //\\ { y : Bool } } like it is rewritten for record values? Why is it permitted for record values, what was the rationale? Perhaps it is related to the next question:
• Currently the nested record definition is available for record values but not for record types. For example, { a.b = 1 } is equivalent to { a = { b = 1 }} but { a.b : Natural } is not equivalent to { a = { b : Natural } }, and in fact { a.b : Natural } is not allowed (it is a parse error). I see that there is an ambiguity: { a.b : Natural } could mean { a : { b : Natural } } or { a = { b : Natural } }. Perhaps we do not want to support the syntax { a.b : Natural } at all, because of that ambiguity?
• Do we want to deprecate //\\ in the future and to remove that operator from the language, if the entire functionality of //\\ is reproduced by /\ after this PR?

[mmhat]

@winitzki I am sympathic to the change, but I think we should change the standard first. Otherwise we risk that this Dhall implementation diverges from it, which may result in confusing errors: For example, dhall <<< '{foo : Text} /\ {bar : Text}' would work, but the same expression yields an error in another -- yet standard-compliant -- implementation.

[mmhat]

I think it would be better to first construct leftTypeOrRecord, then rightTypeOfRecord, and do the check that they are both Left or both Right afterwards in a separate step.

[winitzki]

I think it would be better to first construct leftTypeOrRecord, then rightTypeOfRecord, and do the check that they are both Left or both Right afterwards in a separate step.

I'm not sure I understand your comment. It appears to me that my code already does what you say: it first constructs leftTypeOrRecord, then rightTypeOfRecord, and then checks that they are both Left or both Right in a separate expression.

[mmhat]

What I mean is that you match on leftTypeOrRecord when you construct rightTypeOrRecord.
I think something like the following results in better error messages:

let isTypeOrRecord t = do
        _T <- loop ctx t

        let t' = eval values t
            
        case (_T, t') of
                (VRecord xs, _) -> return (Left xs)

                (VConst _T', VRecord xs) -> return (Right (_T', xs))

                _ -> do
                    let _T'' = quote names _T'

                    case mk of
                        Nothing -> die (MustCombineARecord '∧' l'' _T'')
                        Just k  -> die (InvalidDuplicateField k t _T'')

leftTypeOrRecord <- isTypeOrRecord l
rightTypeOrRecord <- isTypeOrRecord r

case (leftTypeOrRecord, rightTypeOrRecord)
    (Left ..., Left ...) -> ...
    (Right ..., Right ...) -> ...
    (Left ..., Right ...) -> die (TriedToCombineLitWithType ...)
    (Right ..., Left ...) -> die (TriedToCombineTypeWithLit ...)

[winitzki]

@winitzki I am sympathic to the change, but I think we should change the standard first. Otherwise we risk that this Dhall implementation diverges from it, which may result in confusing errors: For example, dhall <<< '{foo : Text} /\ {bar : Text}' would work, but the same expression yields an error in another -- yet standard-compliant -- implementation.

I will make a PR for the standard.

[winitzki]

Started working on a PR for the language standard. Still lots of new tests need to be added.
dhall-lang/dhall-lang#1404

[winitzki]

Added new tests to this dhall-lang/dhall-lang#1404

@mmhat My question is - how can I run tests for dhall-haskell with the new tests that I have added to dhall-lang in that PR?

[TristanCacqueray]

@winitzki you'll have to update the submodule at dhall-haskell/dhall/dhall-lang. You can try locally by pulling the PR in this folder, but I think we'll have to merge the change in dhall-lang before updating the submodule in dhall-haskell.

[winitzki]

@winitzki you'll have to update the submodule at dhall-haskell/dhall/dhall-lang. You can try locally by pulling the PR in this folder, but I think we'll have to merge the change in dhall-lang before updating the submodule in dhall-haskell.

I see. Let me first try to run tests by manually copying dhall-lang over.

[winitzki]

@mmhat I have rewritten the code in that place. I no longer use any extra Left / Right, the code is a lot simpler now. Could you please take a look and let me know if there are further improvements, especially as concerns error messages?

[winitzki]

@mmhat I have run this PR against all regression tests from the PR dhall-lang/dhall-lang#1404 and all passed. (I made sure new tests were getting run.) So, at the moment this looks good.