-
Notifications
You must be signed in to change notification settings - Fork 218
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
unify Combine and CombineTypes #2651
base: main
Are you sure you want to change the base?
Conversation
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.
@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.
VRecord xRs' -> | ||
return xRs' | ||
-- Make sure both are on the Left (both record values) or on the Right (both record types). | ||
rightTypeOrRecord <- case (leftTypeOrRecord, _R', r') of |
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 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.
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 think it would be better to first construct
leftTypeOrRecord
, thenrightTypeOfRecord
, and do the check that they are bothLeft
or bothRight
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.
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.
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 ...)
I will make a PR for the standard. |
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:
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.Combine
operation (/\
) should work on record types just like theCombineTypes
operation (//\\
)Any comments welcome; I am fairly new to this code base and to Haskell.
Open questions:
/\
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:{ 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?//\\
in the future and to remove that operator from the language, if the entire functionality of//\\
is reproduced by/\
after this PR?