* Partially fix whitespace parsing performance regression
This undoes some of the performance regression introduced
in https://github.com/dhall-lang/dhall-haskell/pull/1483
Before #1483:
```
benchmarked Line comment
time 11.86 ms (11.69 ms .. 11.98 ms)
0.999 R² (0.999 R² .. 1.000 R²)
mean 11.84 ms (11.79 ms .. 11.89 ms)
std dev 129.4 μs (107.2 μs .. 164.1 μs)
benchmarked Block comment
time 13.20 ms (13.00 ms .. 13.41 ms)
0.999 R² (0.998 R² .. 1.000 R²)
mean 13.59 ms (13.41 ms .. 13.94 ms)
std dev 600.0 μs (142.2 μs .. 953.7 μs)
```
After #1483:
```
benchmarked Line comment
time 288.7 ms (282.8 ms .. 294.7 ms)
1.000 R² (0.999 R² .. 1.000 R²)
mean 292.3 ms (290.8 ms .. 294.6 ms)
std dev 3.156 ms (2.216 ms .. 4.546 ms)
benchmarked Block comment
time 286.2 ms (280.9 ms .. 292.6 ms)
0.999 R² (0.998 R² .. 1.000 R²)
mean 290.6 ms (288.3 ms .. 292.9 ms)
std dev 3.875 ms (2.866 ms .. 5.500 ms)
```
After this change:
```
benchmarked Line comment
time 61.44 ms (60.37 ms .. 63.03 ms)
0.999 R² (0.997 R² .. 1.000 R²)
mean 61.41 ms (60.74 ms .. 62.25 ms)
std dev 1.341 ms (945.0 μs .. 1.901 ms)
benchmarked Block comment
time 61.83 ms (60.97 ms .. 63.14 ms)
0.999 R² (0.998 R² .. 1.000 R²)
mean 61.16 ms (60.33 ms .. 61.85 ms)
std dev 1.396 ms (1.011 ms .. 1.907 ms)
```
* Correctly parse `https://example.com usingBla`
... as caught by @sjakobi
This is preparatory work for #1454.
This also fixes some cases where dhall would previously accept
malformatted inputs.
The changes to dhall-lsp-server are mostly untested. See #1510.
Co-authored-by: Gabriel Gonzalez <Gabriel439@gmail.com>
* Remove support for fusion
... as standardized in https://github.com/dhall-lang/dhall-lang/pull/792
* Update `dhall.cabal` to match the latest Prelude
* Update `dhall-lang`
... and blacklist tests we don't support yet
* Add missing files to `dhall.cabal`
... by not going through a `Term` intermediate
This gives a ~28% performance in decoding improvement, which means that
cache looks are not faster.
Here are the new decoding benchmarks before and after this change:
Before:
```
benchmarked Issue #108/Binary
time 266.5 μs (265.7 μs .. 267.4 μs)
1.000 R² (1.000 R² .. 1.000 R²)
mean 266.3 μs (265.6 μs .. 267.1 μs)
std dev 2.418 μs (1.891 μs .. 3.436 μs)
benchmarking Kubernetes/Binary ... took 36.94 s, total 56 iterations
benchmarked Kubernetes/Binary
time 641.3 ms (623.0 ms .. 655.4 ms)
0.999 R² (0.997 R² .. 1.000 R²)
mean 679.7 ms (665.5 ms .. 702.6 ms)
std dev 29.48 ms (14.15 ms .. 39.05 ms)
```
After:
```
benchmarked Issue #108/Binary
time 282.2 μs (279.6 μs .. 284.7 μs)
1.000 R² (0.999 R² .. 1.000 R²)
mean 281.9 μs (280.7 μs .. 287.7 μs)
std dev 7.089 μs (2.550 μs .. 15.44 μs)
variance introduced by outliers: 11% (moderately inflated)
benchmarking Kubernetes/Binary ... took 27.57 s, total 56 iterations
benchmarked Kubernetes/Binary
time 499.1 ms (488.1 ms .. 506.6 ms)
0.999 R² (0.998 R² .. 1.000 R²)
mean 498.9 ms (494.4 ms .. 503.9 ms)
std dev 8.539 ms (6.236 ms .. 12.56 ms)
```
There's a slight performance regression for the decoding microbenchmark, but
in practice my testing on real examples matches performance improvements seen
in the larger benchmark based on an example cache product from
`dhall-kubernetes`.
Note that is a breaking change because:
* There is no longer a `FromTerm` nor `ToTerm` class. Now we use the
`Serialise` class and `{encode,decode}Expression` now work on `ByteString`s
instead of `Term`s
* I further narrowed the types of several encoding/decoding utilites to expect a
`Void` for the first type parameter of `Expr`
* This is a regression with respect to stripping 55799 CBOR tags, mainly
because properly handling the tags at every possible point in the syntax tree
would considerably complicate the code
* s/InputType/Encoder
* Rename input* functions on the ToDhall side to encode*
* Haddocks: Use "encoder" instead of "injector"
* s/Type/Decoder
* Haddocks: Stop using the word "parser" for Decoders
* Rename encode{Record,Union} to {record,union}Encoder
The motivation for this is so that `dhall` can be made much faster on very
large projects like `dhall-kubernetes-charts` where vast majority of the time
is spent rendering the very large `Context` when type-checking fails, delaying
the user from getting to the actual error message.
The `Context` also gets in the way of the user noticing the (far more useful)
type diff, but the performance cost is the primary motivation for this change.
If the user wants the context they can still use the `--explain` flag.
* Improve parsing error messages
The main changes are:
* Don't quote expected tokens in the error message (to avoid visual clutter)
* Consolidate expected tokens into simpler categories (e.g. "operator" or
"literal") instead of listing them all
For example, this would be an error message before this change:
```
$ dhall <<< '1 + [1'
dhall:
Error: Invalid input
(stdin):2:1:
|
2 | <empty line>
| ^
unexpected end of input
expecting "!=", "&&", "++", "->", "//", "//\\", "/\", "==", "===", "merge", "toMap", "||", "→", "∧", "≡", "⩓", "⫽", '#', '(', '*', '+', ',', '.', ':', '?', ']', built-in expression, double infinity, double literal, import, integer literal, label, list literal, natural literal, record type or literal, text literal, union type, or whitespace
```
... and this would be an error message after this change:
```
$ dhall <<< '1 + [1'
dhall:
Error: Invalid input
(stdin):1:4:
|
1 | 1 + [1
| ^^^^
unexpected " [1<newline>"
expecting (, import, keyword, label, or literal
```
* Fix test failures
* Fix warnings
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
