Dhall-haskell: Migrate to the HsYaml package

Created on 9 Dec 2018  路  11Comments  路  Source: dhall-lang/dhall-haskell

The yaml package doesn't work with GHCJS because it depends on a C library, so if we can migrate to using the HsYaml package then we can render YAML for the "Try Dhall" page.

jsoyaml

Most helpful comment

@jneira Can you elaborate on the semantics of "quoted scalars if needed"? Whether a scalar needs to be quoted really depends on the YAML schema resolver your application defines for a YAML file to be used; the YAML 1.2 spec pre-defines 3 schema resolvers, "failsafe", "core" and "JSON" (see https://yaml.org/spec/1.2/spec.html#Schema) -- and applications can also opt to define their own domain specific schema if needed; and when HsYAML adds support for encoding, it will defer the decision whether to quote partly to the schema resolver you ask it to use in a dual way to the way the decoding currently works, which too defers to the selected YAML schema resolver to resolve which primitive tag/type a scalar node is to be decoded into...

PS: ...and btw, we do have Vijay working on the GSOC HsYAML project this year! https://twitter.com/vijayphoenix1/status/1129668526405328896 ! :-)

All 11 comments

Last time I looked at the HsYaml package I noticed that the parsing part there is excellent, but there's apparently no nice way to "render" YAML (which is the only thing we use yaml for), so we'd have to code the whole rendering pipeline

@f-f: Oh, I didn't realize that. Maybe we could hack it by transmitting a JSON object across the Haskell/JavaScript boundary and then doing the YAML rendering in JavaScript

I got the same problem for eta and just replace the call to yaml with a call to a java external lib (jackson): https://github.com/typelead/eta-hackage/blob/master/patches/dhall-json-1.2.5.patch#L77

How much control would you need over the generated YAML (i.e.in terms of formatting options, specifically regarding flow-style or indentation)?

Fwiw, I've suggested completing the yaml-dumping part of the HsYAML pipeline as a GSOC idea for this year, so there's a good chance this will be addressed one way or another this year.

@hvr: The only rendering thing that I care about is that multi-line strings are rendered in YAML as "literal" multi-line strings (i.e. ones prefixed with !). Other than that, I'm pretty flexible

@Gabriel439 there's afaik no !-prefixed block literals, see https://yaml.org/spec/1.2/spec.html#id2793652

I suspect you meant the literal blockstyle ones (i.e. using the | indicator), possibly with an indentation indicator (when the multi-line strings happens to start with leading whitespace) and blockchomping indicators for when the string has non-trivial trailing whitespace?

@hvr: Whoops, yes, I meant |

Since #941, we are using Data.Yaml.encodeWith :: ToJSON a => EncodeOptions -> a -> ByteString to " quoted scalars if needed" so HsYAML should have that feature to be usable.

@jneira Can you elaborate on the semantics of "quoted scalars if needed"? Whether a scalar needs to be quoted really depends on the YAML schema resolver your application defines for a YAML file to be used; the YAML 1.2 spec pre-defines 3 schema resolvers, "failsafe", "core" and "JSON" (see https://yaml.org/spec/1.2/spec.html#Schema) -- and applications can also opt to define their own domain specific schema if needed; and when HsYAML adds support for encoding, it will defer the decision whether to quote partly to the schema resolver you ask it to use in a dual way to the way the decoding currently works, which too defers to the selected YAML schema resolver to resolve which primitive tag/type a scalar node is to be decoded into...

PS: ...and btw, we do have Vijay working on the GSOC HsYAML project this year! https://twitter.com/vijayphoenix1/status/1129668526405328896 ! :-)

Nice! Didn't know about its use of YAML schemas

This was fixed by https://github.com/dhall-lang/dhall-haskell/pull/1248! :)

Was this page helpful?
0 / 5 - 0 ratings