Interest in json-to-dhall and yaml-to-dhall?

[joneshf]

We have programs for taking Dhall and making JSON. Is there any interest in a program that takes JSON and makes Dhall? I often find myself reaching for jq as an alternative, but its UX isn't the best for me. Similarly for yq.

Thoughts?

[Gabriella439]

Yeah. There is a discussion of possible language integration integration:

dhall-lang/dhall-lang#121

... but the first step could be implementation of the ideas in that thread as a standalone executable. I think the main consensus from that thread was that any JSON to Dhall conversion would need to specify a type annotation if that's alright with you. In other words, it would be something like:

$ json-to-dhall --type './schema.dhall' < ./input.json > ./output.dhall

[joneshf]

Sounds good!

[joneshf]

Giving this some thought, looks like there are a couple ways to approach.

Convert and type check together

1. Parse type annotation to Expr Src X
2. Parse JSON to Value
3. Traverse Value with type annotation
   • Check types. Since Value is a bit dynamically typed–Double, Integer and Natural all look the same, for instance–we'll need to know which one we're supposed to have.
   • Convert to Expr s a
4. Return Expr s a

Convert in passes

1. Parse type annotation to Expr Src X
2. Parse JSON to Value
3. Convert Value to Expr s a
4. Coerce values where appropriate based on the annotation
   • Again, Double, Integer, and Natural all look the same. In Value they're all Scientific, which corresponds to Double in Expr s a. We ought to be able to try and coerce to one of the other types if it's supposed to or fail at this point.
5. Return Expr s a

---

Maybe there are other approaches. Do you have a preference?

[joneshf]

Hmm, given that Null is a thing in Value, does converting in passes and coercing make sense? I guess we'd give a Null the type forall (a : Type) -> Optional a and coerce it afterward?

I wonder if there are other cases to account for?

[Gabriella439]

I assumed that this would require the first approach (Convert and type check together) mainly due to handling null. The reason why is that you can't tell what the principal type of any JSON value is, since a value like 1 could have type Integer, Optional Integer, Optional (Optional Integer), etc.

[joneshf]

Sounds good.

Also, how should unions work? If you have:

< Name : Text >

What JSON corresponds to that?

What if you have:

< FirstName : Text | LastName : Text >

[Gabriella439]

@joneshf: Yeah, this is one of the tricky bits to deal with. My intuition is either (A) don't support union types at all or (B) take the first union type that matches (doing depth-first recursive search if necessary)

I would go with (A) and not support union types for now until the logic for dealing with sum types has been properly formalized. The reason why is that in the process of formalization one algorithm for disambiguating these cases might be simpler and clearer to specify than others and I don't want users to depend on the wrong algorithm until we know which one it is.