* 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.
This expands the "Try dhall" page to serve as a functional home page for
"dhall-lang.org" in the short term by making the following changes:
* Adding a navigation bar to the top that links to useful resources and
official integrations
* Adding a quick summary explaining what Dhall is
This updates all of the `README`s to:
* centralize all of the build/install/develop information in the
top-level `README`
* get the nested `README`s to use a consistent style
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`.
Gabriel Gonzalez
Simon Jakobi
Javier Neira
Robbie McMichael
quasicomputational
Dmitry Dolgov
Profpatsch
antislava
Fabrizio Ferrai
Justin Woo
David Virgilio