* Add the `--preserveNull` flag and omit null fields by default on `dhall-to-yaml`
fixes#1354
* Restore the `--omitNull` flag and apply `--preserveNull` to `dhall-to-json`
* Adjust examples that return null fields
* Mention the default behaviour regarding nulls
* Null -> null
* Fix `--version` flag handling for `dhall-json` package
Fixes https://github.com/dhall-lang/dhall-haskell/issues/1198
This changes version to be a separate constructor for options parsing,
in order to make invalid states unrepresentable and to fix issues like
the above one.
* Undo `allowImports` changed
This was a change I forgot to stash while working on the fix for the
`--version` flag
* Fix missing `Paths_dhall_json` in `dhall-json.cabal`
* Add `--file` option to `dhall-json` executables
Fixes https://github.com/dhall-lang/dhall-haskell/issues/1096
* s/JSON/expression/
... as caught by @sjakobi
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
* s/expression/YAML expression/
... as caught by @sjakobi
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
* Change the program descriptions for `{json,yaml}-to-dhall`
... as suggested by @sjakobi
After #989 and #993 the use of the `yaml` package is isolated in the lib modules `Dhall.Yaml` and `Dhall.YamlToDhall` so it is easier to add support for compilers that cant use the `yaml`package like eta or ghcjs.
With this one we would add support for [eta](https://eta-lang.org/), a fork of ghc that compiles to jvm bytecode.
Main changes:
* Add conditional to cabal file and cpp conditions to the main modules for yaml to use a specific module for eta, `Dhall.Yaml.Eta` that replaces calls to the `yaml`package to ffi calls to the java lib [jackson](https://github.com/FasterXML/jackson), one of the most popular ones in the java world.
* Add the java files that contains the ffi calls
* Mark `buildable: False` the subpackages that cant be built by eta for now
One effect of use the cabal file for cabal and etlas (the build tool for eta) is stack and cabal builds show those warnings:
```
Warning: Cabal file warning in D:\ws\eta\dhall\dhall-haskell\dhall-json\dhall-js
on.cabal@ 69:9:
Unknown field: "maven-depends"
Warning: Cabal file warning in D:\ws\eta\dhall\dhall-haskell\dhall-json\dhall-js
on.cabal@ 74:9:
Unknown field: "java-sources"
```
I've not found a way to avoid them other than use another file for etlas build (`etlas.dhall`). It would suppose duplicate most of the logic, though.
Before, `dhall-to-json`/`dhall-to-yaml` would use approximate
representations for special `Double` values. Specifically, `NaN`
would encode as `null` and `±Infinity` would encode as the minimum
and maximum `Double` values.
After this change, YAML will now use `nan`/`inf`/`-inf` to encode
these values (since special `Double` values are natively supported
by YAML) and the JSON encoding will reject them by default. The
user can restore the old behavior for the JSON encoding by enabling
the `--approximate-special-doubles` flag.
Allow to generare quoted scalars if needed via providing a custom encode
options to Data.Yaml.encodeWith. So far two corner cases from yaml
itself (an empty scalar, and special strings) are omitted in the
implementation.
... as proposed in https://github.com/dhall-lang/dhall-kubernetes/issues/46#issuecomment-468530601
`--omitEmpty` is the same as `--omitNull` except it also omits fields that
are empty records. To be precise, it omits fields whose transitive fields
are all `null` (and an empty record is a special case of a record whose
transitive fields are all `null` since it is vacuously true when there are
no fields).
This allows Dhall configurations that target YAML to avoid having to nest
sub-records inside of an `Optional` value. Omitting unnecessary `Optional`
layers reduces the number of default values that the configuration format
needs to thread around.
The motivation for this change is:
* To catch build failures in downstream packages whenever we make a breaking
change to the `dhall` API
* To reduce the amount of work I need in order to cut a release for all of
these packages
* To better share Nix/CI-related logic between the projects
Note that I have not yet migrated `dhall-nix` in. I'm waiting for
https://github.com/dhall-lang/dhall-nix/issues/17 to be fixed since
`dhall-nix` is incompatible with later versions of `megaparsec` due to
`hnix`.
Simon Jakobi
mujx
Gabriel Gonzalez
Javier Neira
Dmitry Dolgov