* 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`
This adds a new `--records-loose` flag and changes the default behavior
to `--records-strict`
The rationale for this change is so that this default behavior helps
more when users are still experimenting with the appropriate type to
use to decode a large and messy YAML file.
For example, suppose a user is trying to translate the following YAML
to Dhall:
```yaml
foo: 1
bar: true
```
... and they start with a empty Dhall type which they plan to fix in
response to error messages. They'd get a surprising success:
```bash
$ yaml-to-dhall '{}' < ./example.yaml
{=}
```
... because the old default behavior is to ignore extra fields in the
YAML. However, if we're strict by default then users don't have to
apply the `--records-strict` flag to get feedback on what they need
to change.
* 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
* Handle empty alternatives when converting from JSON
Fixes https://github.com/dhall-lang/dhall-haskell/issues/1074
`dhall-to-{json,yaml}` treat empty alternatives as strings of the
same name, but `{json,yaml}-to-dhall` were missing the corresponding
logic to decode strings to empty alternatives, which this change
fixes.
This also ensures that the conversion logic contains no more
`undefined`s, by making the union conversion branch total.
* Clarify successful cases for union handling
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
* Add missing trailing newline
... as caught by @sjakobi
* Fix `dhall-json`'s support for preserving alternative names
... as caught by @sjakobi in the course of #1077
The code has to be updated to reflect the new normal forms for
union literals
* Add tests
... as suggested by @sjakobi
Related to: https://github.com/dhall-lang/dhall-haskell/issues/1039
We'll probably never see indices that exceed the space of an `Int` and
the interpreter would probably not be able to handle 9223372036854775807
nested binders anyway.
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.
In yaml-0.11, Text.Libyaml was split into the libyaml package. Hence,
as dhall-json imports that module, a libyaml dependency is needed when
yaml >= 0.11. This necessitates an automatic flag.
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.
* Initial draft of the json-to-dhall tool
* Homogenous JSON maps -> Dhall association lists. Bower example.
* Default conversion options. Ghci examples in function annotations.
* Added type signature to text color highlighting functions (error
reporing)
* Removed TypeApplications extension
* Explicit semigroups
* Disable ghc < 8.0 build
* Type specifications for 'None's (e.g. None Integer instead of just None)
* New style for unions, e.g.: < Left : Text | Right : Integer >.Right +1
... as standardized in https://github.com/dhall-lang/dhall-lang/pull/438
This also adds `dhall-json` support for empty alternatives
In particular, this translates empty alternatives to strings encoding the alternative name
```haskell
-- ./example.dhall
let Role = < Wizard | Fighter | Rogue >
in [ Role.Wizard, Role.Fighter ]
```
```
$ dhall-to-json <<< './example.dhall'
["Wizard","Fighter"]
```
... 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.
These aren't fully static executables (they still have some
`/nix/store` references), but they at least compile Haskell dependencies
statically. That means that they can be `nix-env --install`ed side-by-side
with other Haskell executables, which would otherwise conflict with an
error like this one:
```
error: packages '/nix/store/hrxnlwlsiw5jjjkq5v6ihcwb0shx4fga-dhall-1.20.1/lib/li
nks/libHSbasement-0.0.8-8QjArDsw3GWCcbHE5iqtz3-ghc8.4.3.dylib' and '/nix/store/d
2y5373anwf1q3h86ar3lljk11k1lq0h-dhall-json-1.2.6/lib/links/libHSbasement-0.0.8-8
QjArDsw3GWCcbHE5iqtz3-ghc8.4.3.dylib' have the same priority 5; use 'nix-env --s
et-flag priority NUMBER INSTALLED_PKGNAME' to change the priority of one of the
conflicting packages (0 being the highest priority)
```
This adds four new sections to the page after the live demo which highlight
the common themes that I notice people use when communicating the value of
Dhall to others on social media:
* The first section emphasizes the element of delight in using the language for
people who are into elegance and quality
* The second section focuses on more pragmatic people who are sick of YAML and
just want a reasonable alternative that they can convince their manager to
adopt
* The third section appeals to the LangSec crowd that wants an uncompromising
and secure foundation for what they are buliding
* The last section targeted at the skeptic who thinks that Dhall is an ivory
tower language not suited for real-world problems.
The second crowd (YAML emigrants) is the audience that I'm targeting the
most strongly at the moment, but I didn't want to lead with a negative reason
adopt by focusing on the limitations of YAML, so I put the section on delight
first so that we could start with a more positive tone.
