... as caught by @singpolyma
`Dhall.Binary.unApply` was failing to uncurry functions due to the presence of
`Note` constructors. This caused `dhall encode` to produce different
results from `dhall hash` since the latter was normalizing the expression
(and therefore removing `Note` constructors) whereas the former was not.
Related to https://github.com/dhall-lang/dhall-lang/issues/333
This softens the language to point out that we can't guarantee
that we are secure against malicious expression but we do aim to be
and we don't settle for less.
... 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 commit fixes an issue that made the last branch of the completer
unreachable.
The second to last branch was always `True`:
```
> split (== '.') "anything"
["anything"]
```
Signed-off-by: Basile Henry <bjm.henry@gmail.com>
Fixes#832 832
This includes two changes:
* Fix a missing newline at the end of `dhall format` output when not using
the `--inplace` option
* Better align ASCII output
.. as caught by @Profpatsch in:
https://github.com/dhall-lang/dhall-haskell/pull/812#issuecomment-462134701
Before this change the location was always being reported as `(stdin):1:1`
because the `SourcedException` kept getting modified with a broader
source location in the `Note` branch of `loadWith`.
This was originally done so that alternative imports would show the entire
source span, but it mistakenly just kept bubbling up regardless of whether or
not there were alternative imports.
Instead, this includes an approximate source span for alternative imports.
The source span bounds are correct but the contents just show which imports
were alternated, even if they might have been buried in a larger expression.
For example, if the original expression had been:
```haskell
Some ./x ? None ./y
```
... then the source span for the error message would display just:
```haskell
./x ? ./y
```
... which is probably as good as it will get for now.
The format for the save file is a plain Dhall file containing REPL commands.
This will hopefully mean that the save file can be edited manually if need be
without too much effort.
Signed-off-by: Basile Henry <bjm.henry@gmail.com>
The motivation behind this change is so that users can freeze remote imports
(like the Prelude) but ignore local imports so that subsequent runs of the
interpreter reflect changes to local files and environment variables.
The reasoning behind this is that there are two primary benefits of integrity
checks:
* Improved security
* Caching
... and one downside which is that updates to those imports are not pulled in
until the integrity check is updated or removed.
However, environment variables and local file paths do not benefit from
improved security or caching, so there is only a downside to freezing them.
Specifically:
* Environment variables and local file paths are both cheap to resolve
... so they don't really benefit from caching.
To be precise, they *could* benefit from caching if the cache expression is
cheaper to parse and normalize compared to the original file. For those
cases there is still an `--all` flag to freeze all imports.
* Environment variables and local file paths are trusted
For example, when a user runs the `dhall` executable they are implicitly
trusting their filesystem which provides that executable. Similarly, when
they run `dhall` without an absolute path they are implicitly trusting that
their `PATH` environment variable has not been compromised to point to a
malicious executable.
Up until now, Dhall's threat model has always been that local imports are
trusted but remote imports are not, so this is consistent with that threat
model.
... so as far as environment variables and local files are concerned there are
only downsides to freezing them and no up-side. This is why this change
no longer freezes them.
This also renames `hashImport` to `freezeImport` for more terminology
consistency.
This is useful for integrating dhall to build systems where dhall
expressions (e.g. of type `Text`) are build products.
This also renames the `--list` flag to `--transitive-dependencies`
Fixes https://github.com/dhall-lang/dhall-lang/issues/357
This uses `Text.Megaparsec.Char.Lexer.decimal` which matches the Dhall
grammar. The previous `decimal` parser was also accepting non-standard
hex and octal literals.
