Fixes#1559.
This requires aeson-yaml >= 1.0.5.0 since older versions
incorrectly encode empty objects.
The raised bound also fixes#1560. A regression test is included.
This causes text literals to be formatted as multi-line strings
whenever they contain at least one newline and at least one non-newline
character. "Spacers" like `"\n\n"` continue be formatted as single-line
strings. If the heuristic turns out to be too eager to choose a
multi-line layout, we can refine it later.
This partially addresses #1496.
Also
* update some variable names
* use 80-column "smart" layout consistently
This updates the `dhall` package to have 100% haddock coverage and
also updates CI to enforce this going forward.
This also includes a change to deprecate the `X` type synonym, which
I noticed along the way
* 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
* Enable --pretty by default for dhall-to-json
* add Deprecation notice into dhall-to-json help
* update dhall-to-json output examples in src/Dhall/JSON.hs
Fixes a type mismatch error message which mentions JSON.
Fixes an "arithmetic overflow" exception which occurs when attempting to
parse a negative number as a `Natural`.
When enabled, we handle protected imports as if the semantic cache was
empty:
* Protected imports are resolved again, downloaded or read from
the filesystem as necessary.
* Protected imports are β-normalized, not αβ-normalized.
* Protected imports are checked against their SHA256 hashes,
failing to resolve if they don't match.
Context:
https://github.com/dhall-lang/dhall-haskell/pull/1275#issuecomment-528847192
Closes#1185.
This mostly reverts "Add support for multi-`let` (#675)" /
8a5bfaa3b9.
Also:
* Add fields for Src
This is useful for to make 'Note's less noisy during debugging:
first srcText expr
* Fix `yaml-to-dhall` support for empty objects
`yaml-to-dhall` was decoding an empty object into:
```dhall
[] : { mapKey : Text, mapValue : Text }
```
... instead of:
```dhall
[] : List { mapKey : Text, mapValue : Text }
```
... which this change fixes
* Add missing test files
* Hopefully fix test failure on Windows
I suspect that the test failure is due to the locale for the test suite
not being set to UTF8
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.