Fixes https://github.com/dhall-lang/dhall-haskell/issues/1470
`dhall freeze` no longer attempts to use the cache to fetch an import since
the cache might not match the underlying import any longer. Instead,
`dhall freeze` now always attempts to fetch the underlying import to
compute the new hash.
* Resolve#1451: fix `format --check` given STDIN input.
I'm not really sure if this is the "best" approach so let me know if you
know a way to simplify this.
The issue was that `getExpressionAndHeader` was doing a second
`IO.getContents` (thus reading STDIN twice).
* Rename `Input` constructor.
If you run `dhall --explain` to explain a type error from a list with
mismatched elements, the index of the offending term was wrong. For a
minimal example, you can run:
dhall --explain <<<'[0, True]'
The problem is that `i` is an index into the tail of the list, not into
the whole list. The fix is just to add one to it to correct for the
missing head.
* Update `Dhall.Tutorial` module
This overhauls the `Dhall.Tutorial` module to reflect recent changes to
the language (and also to link to external documentation when possible).
* Fix doctests
* Rephrase import syntax caveat
... as suggested by @sjakobi
* Explain `<<<`
... as suggested by @sjakobi@
* Rephrase things
... as suggested by @sjakobi
* `s/The annotated/This/`
... as caught by @sjakobi
* Add commas to description of link to built-ins reference
... as caught by @sjakobi
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
* Remove paragraph describing role of Prelude
* Update dhall/src/Dhall/Tutorial.hs
... as suggested by @sjakobi
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
* Rename Interpret to FromDhall
The "Interpret" name remains in `InterpretOptions`, which are
actually used for marshalling in both directions.
* s/injectThenInterpretIsIdentity/embedThenExtractIsIdentity
* s/Inject/ToDhall
* s/shouldInjectInto*/shouldEmbedAs*
* Keep Interpret and Inject as constraint synonyms for compatibility
… as suggested by @Gabriel439.
* Move prefix out of renderSrc
This reduces the complexity of renderSrc slightly without affecting
anything else much.
* Make formatting of comments idempotent
Fixes#1413. Previously the formatter would insert an additional line
break before some comments whilst preserving existing line breaks. In
order to restore idempotent behaviour, we need to strip a leading
newline character from the comment string in those cases, if present.
* Test idempotency when formatting comments
Test case taken from @AJChapman's bug report (#1413).
* Change argument order of renderSrc
Reads a bit more idiomatic, as suggested by @sjakobi.
* [#1392] Injecting Data.Map
* injecting via Generic
* Explicit instance
* Cleanup code
* Minor code cleanup
* Property testing for Inject/Interpret
* Refactor test
* Adding TypeApplications to .cabal
* No more TypeApplications
* Simplified tests using extract
* Added test for Text amnf fixed Natural import
* Update dhall/dhall.cabal
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
* Update dhall/dhall.cabal
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
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
* [#1395] Marshalling Set and HashSet
* Update dhall/src/Dhall.hs
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
* Update dhall/src/Dhall.hs
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
* Added distinctList
* setFromDistinctList updates
* Doctests abour ordering
* both set and hashset can ignore or fail with duplicates
* Comments on instances
* Moved length computation deeper
* Little wibble
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
* Add support for leading separators
... as standardized in https://github.com/dhall-lang/dhall-lang/pull/755
Note that this does not yet change the formatter to use them
* Update `dhall-lang` submodule
* Fix `dhall.cabal` to mention new Prelude files
* Remove duplicate lines
* Resolves#1408: Add more detail in `--explain` when `toMap` has the wrong type.
Specifically, add common reason of using `{}` for record value.
For example,
``` shell
echo 'toMap {}' | ~/.local/bin/dhall
```
Outputs
> Error: ❰toMap❱ expects a record value
>
> Explanation: You can apply ❰toMap❱ to any homogenous record, like this:
>
>
> ┌─────────────────────────────────────────────────────────────────────┐
> │ let record = { one = 1, two = 2 }
> │
> │ in toMap record : List { mapKey : Text, mapValue : Natural}
> │
> └─────────────────────────────────────────────────────────────────────┘
>
>
> ... but the argument to ❰toMap❱ must be a record and not some other
> type.
>
> Some common reasons why you might get this error:
>
> ● You accidentally provide an empty record type instead of an empty
> record when
> using ❰toMap❱:
>
>
> ┌──────────┐
> │ toMap {} │
> └──────────┘
> ⇧
> This should be ❰{=}❱ instead
>
> ────────────────────────────────────────────────────────────────────────────────
>
> 1│ toMap {}
>
> (stdin):1:1
* Add type annotation to `toMap` suggestion.
* #1381 Word* to Natural
* Added instance for Word
* Got rid of linting issues
* Added docsets
* Added comments
* Revert Crypto to master version
* Spread the doctests
* Improve Docstring
This includes some simplifications/optimizations for the `ToTerm DhallDouble` instance.
Most notably we let `cborg` take care of the correct encoding of NaNs:
See `Codec.CBOR.Write.doubleMP`:
977c0c0820/cborg/src/Codec/CBOR/Write.hs (L571-L573)
merge-expressions with additional arguments are also formatted with
consistent indentation for all arguments. E.g.
merge
{ x = Natural/even }
< x >.x
1111111111111111111111111111111111111111111111111111111111
Fixes a small regression introduced in 7634ee7.
The loss of indentation for toMap and merge was due to
75e6cc5ca7. I have included Some for
consistency.
Fixes#1376.
Also improve format test failure messages
* Fix pretty-printing precedence of `toMap`
Fixes https://github.com/dhall-lang/dhall-haskell/issues/1358
* Also correctly format `merge` expressions without a type annotation
... as suggested by @sjakobi
* Add test for formatting "function-like" expressions
This verifies that the code correctly handles `toMap` expressions with
type annotations as @sjakobi was asking about
