I've just noticed that dhall-to-yaml doesn't transform Map Natural Text which I use to define .sublime-syntax match patterns (by converting List/indexed into Map)
block-comment:
- captures:
- mapKey: 1
mapValue: punctuation.definition.comment.scl.scl
match: (/\*)(?:\s*(?=\s|(\*/)))?
push:
- meta_scope: comment.block
- pop: true
captures:
- mapKey: 0
mapValue: punctuation.definition.comment.scl.scl
match: \*/
Unlike JSON, key in YAML can be any type _except_ List and Record, which are:
TextNaturalIntegerDoubleBoolOptional Type, except List and RecordAlso, some key type that I think need to be converted too on dhall-to-json:
None Text, --omitEmpty will delete record fieldSome Textlet any_Union_that_has = < T1: Text | T2: Optional Text | T3 >TextTo be clear: You'd like your example to be converted like this?
```yaml
block-comment:
Yes
Work on this issue should probably wait for the switch to aeson-yaml as planned in https://github.com/dhall-lang/dhall-haskell/pull/1248#issuecomment-537304799.
If we want to generate and parse YAML with non-Text keys, we will have to move away from the current Dhall-JSON-YAML pipeline, where Dhall expressions are first encoded as JSON and then translated to YAML. It would probably make sense to move the HsYAML-based logic to a separate package dhall-yaml(?) then. The aeson-yaml-based code could possibly stay in dhall-json. In any case it would be nice to get rid of the gpl flag again.
I have made a separate issue for discussing dhall-yaml: https://github.com/dhall-lang/dhall-haskell/issues/1435.
Most helpful comment
If we want to generate and parse YAML with non-Text keys, we will have to move away from the current Dhall-JSON-YAML pipeline, where Dhall expressions are first encoded as JSON and then translated to YAML. It would probably make sense to move the
HsYAML-based logic to a separate packagedhall-yaml(?) then. Theaeson-yaml-based code could possibly stay indhall-json. In any case it would be nice to get rid of thegplflag again.