Since Val contains functions, its Show instance cannot be
derived in the usual way without exposing a non-standard Show
instance for (Val a -> Val a). Instead, we rely on the user to
provide a fitting instance, e.g. by importing Text.Show.Functions.
Fixes https://github.com/dhall-lang/dhall-haskell/issues/1306
The following comment describe how this works in depth:
https://github.com/dhall-lang/dhall-haskell/issues/1129#issuecomment-532928798
The short explanation is that we can substantially speed up type-checking
by not substituting `let` expressions and instead adding the bound variable
to the context. This is the same as the type-checking "fast path" that
we had before adding dependent types, except this time it works even in the
presence of dependent types.
The main difference is that we add the `let`-bound type *and* value to the
context and use `Dhall.Eval.conv` to perform equivalence checking instead of
`Dhall.Core.judgmentallyEqual`.
* Refactor `Dhall.Eval`
This updates the style of `Dhall.Eval` to match the stylistic
and naming conventions of the rest of the `dhall` package.
* Import `Data.Set` fully qualified
... as suggested by @sjakobi
* Re-enable warnings
... as wished by @sjakobi
* Remove `{eval,conv,quote}E` synonyms
... as suggested by @sjakobi
* INLINE `qVar`
... literally
... as suggested by @sjakobi
* Remove unnecessary `MIN_VERSION_base(4,8,0)`
... as caught by @sjakobi
We still need `CPP` elsewhere within the same file, though
* Fix style of `vProjectByFields` function
... as caught by @sjakobi
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
Previously, normalizing `Natural/subtract 0` would result in this
error:
⊢ Natural/subtract 0
Error: Compiler bug
An ill-typed expression was encountered during normalization.
Explanation: This error message means that there is a bug in the Dhall compiler.
You didn't do anything wrong, but if you would like to see this problem fixed
then you should report the bug at:
https://github.com/dhall-lang/dhall-haskell/issues
CallStack (from HasCallStack):
error, called at src/Dhall/Eval.hs:865:38 in dhall-1.25.0-FCOZ7uxqivz8dkVwuN7aED:Dhall.Eval
This updates the dhall-lang submodule to include a new testcase added
in https://github.com/dhall-lang/dhall-lang/pull/692.
* Remove Dhall.X and replace with Data.Void
This commit removes the Dhall.X module and the Dhall.X.X type,
preferring the use of Data.Void.Void. As I'm sure a lot of people are
actually using X, I've added a type-alias type X = Void. However,
pattern matching on X would be a breaking change.
Fixes#1120.
* Restore unsafeCoerce
* Fix regression
* Unused
* Reorganise exports
* Fix dhall-nix
* Another fix
* Fix Dhall.LSP.Backend.Typing
* Fix dhall-bash
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.
Fixes https://github.com/dhall-lang/dhall-lang/issues/579
`Natural/fold` was misbehaving on GHCJS due to the use of `Natural`
arithmetic (for some reason). This is a problem I've seen and fixed
before, but needed to be fixed again after the migration to the new
`Dhall.Eval` normalization engine.
The fix is easy: use `Integer` instead of `Natural` for the accumulator
of the fold and the bug disappears.
- Dhall.Eval: new evaluator, conversion checker and normalizer.
There is no standalone alpha normalizer yet.
- There is a new option "new-normalize" for dhall executable, which uses
the new normalizer.
- Type checker is unchanged.
- new implementation: alphaNormalize, judgmentallyEqual, normalize
- normalizeWith takes a Maybe ReifiedNormalizer argument now, and switches to
the new evaluator whenever the input normalizer is Nothing
- QuickCheck test for isNormalized removed, because we don't support evaluation
of ill-typed terms, which the test would require.
