yaml-to-dhall: how to force a particular union alternative when alternatives have the same type?

[ari-becker]

Running:

yaml-to-dhall '< Foo : Natural | Bar : Natural >' <<< 'Foo: 20'

Results in:

Error: $: Dhall type expression and YAML value do not match:

Expected Dhall type:
< Bar : Natural | Foo : Natural >

YAML:
Foo: 20

while running:

yaml-to-dhall '< Foo : Natural | Bar : Natural >' <<< '20'

Results in:

< Bar : Natural | Foo : Natural >.Bar 20

I understand that I can use --unions-strict to turn the second case into an error, but is there a way that I can get yaml-to-dhall to reliably return < Bar : Natural | Foo : Natural >.Foo 20?

Discovered while trying to parse into this type: https://github.com/coralogix/dhall-utility-library/blob/8ad768e4a7ab313b5ee1b01c093ffdd1fef379c7/kubernetes/Space.dhall

[Gabriella439]

@ari-becker: There's not a way to do this that I'm aware of. The reason why reordering the union types does not help is because the schema is interpreted (including normalization) and normalizing a union type sorts the alternatives.

[ari-becker]

@Gabriel439 I understand how the normalization process sorts the alternatives, I think my question was more about whether it was possible to parse Foo: 20 as < Bar : Natural | Foo : Natural >.Foo 20, as then the YAML is trying to be deterministic.

You can see (linked to this issue) how I'm working around this.

[Gabriella439]

@ari-becker: Yeah, I think that should be possible to implement a feature like that. I think the main guidance I need from others is if we should do this by default or if this behavior should be guarded behind a flag

[german1608]

@Gabriel439: From my POV there should be a flag for this feature.

I have several questions, regarding the implementation details.

• Is the input always going to be a possible alternative from a union type?
• What would we expect from passing to the tool something that is not a YAML record with a single property?
• If we have an schema like this < Bar: { Foo: Natural } | Foo : Natural > should the flag make the tool go by the second alternative? Currently yaml-to-dhall, given Foo: 1 as an expression, returns < Bar: { Foo: Natural } | Foo: Natural >.Bar { Foo = 1}>.

The flag names I'm thinking of are:

• --union-force
• --force-alternative

[Gabriella439]

I probably won't be able to get to this soon, but I'd accept a pull request adding support for this if somebody were interested in implementing this