Commit graph

24 commits

Author SHA1 Message Date
Kyle Miller
28cf146d00
fix: make sure monad lift coercion elaborator has no side effects (#6024)
This PR fixes a bug where the monad lift coercion elaborator would
partially unify expressions even if they were not monads. This could be
taken advantage of to propagate information that could help elaboration
make progress, for example the first `change` worked because the monad
lift coercion elaborator was unifying `@Eq _ _` with `@Eq (Nat × Nat)
p`:
```lean
example (p : Nat × Nat) : p = p := by
  change _ = ⟨_, _⟩ -- used to work (yielding `p = (p.fst, p.snd)`), now it doesn't
  change ⟨_, _⟩ = _ -- never worked
```
As such, this is a breaking change; you may need to adjust expressions
to include additional implicit arguments.
2024-11-13 16:22:31 +00:00
Kim Morrison
a04b476431
chore: remove instBEqNat, which is redundant with instBEqOfDecidableEq but not defeq (#5694) 2024-10-16 04:42:22 +00:00
Kyle Miller
fdd5aec172
feat: better #eval command (#5627)
This refactors and improves the `#eval` command, introducing some new
features.
* Now evaluated results can be represented using `ToExpr` and pretty
printing. This means **hoverable output**. If `ToExpr` fails, it then
tries `Repr` and then `ToString`. The `eval.pp` option controls whether
or not to try `ToExpr`.
* There is now **auto-derivation** of `Repr` instances, enabled with the
`pp.derive.repr` option (default to **true**). For example:
  ```lean
  inductive Baz
    | a | b

  #eval Baz.a
  -- Baz.a
  ```
It simply does `deriving instance Repr for Baz` when there's no way to
represent `Baz`. If core Lean gets `ToExpr` derive handlers, they could
be used here as well.
* The option `eval.type` controls whether or not to include the type in
the output. For now the default is false.
* Now things like `#eval do return 2` work. It tries using
`CommandElabM`, `TermElabM`, or `IO` when the monad is unknown.
* Now there is no longer `Lean.Eval` or `Lean.MetaEval`. These each used
to be responsible for both adapting monads and printing results. The
concerns have been split into two. (1) The `MonadEval` class is
responsible for adapting monads for evaluation (it is similar to
`MonadLift`, but instances are allowed to use default data when
initializing state) and (2) finding a way to represent results is
handled separately.
* Error messages about failed instance synthesis are now more precise.
Once it detects that a `MonadEval` class applies, then the error message
will be specific about missing `ToExpr`/`Repr`/`ToString` instances.
* Fixes a bug where `Repr`/`ToString` instances can't be found by
unfolding types "under the monad". For example, this works now:
  ```lean
  def Foo := List Nat
  def Foo.mk (l : List Nat) : Foo := l
  #eval show Lean.CoreM Foo from do return Foo.mk [1,2,3]
  ```
* Elaboration errors now abort evaluation. This eliminates some
not-so-relevant error messages.
* Now evaluating a value of type `m Unit` never prints a blank message.
* Fixes bugs where evaluating `MetaM` and `CoreM` wouldn't collect log
messages.

The `run_cmd`, `run_elab`, and `run_meta` commands are now frontends for
`#eval`.
2024-10-08 20:51:46 +00:00
Joachim Breitner
7d60d8b563
feat: safer #eval, and #eval! (#4810)
previously, `#eval` would happily evaluate expressions that contain
`sorry`, either explicitly or because of failing tactics. In conjunction
with operations like array access this can lead to the lean process
crashing, which isn't particularly great.

So how `#eval` will refuse to run code that (transitively) depends on
the `sorry` axiom (using the same code as `#print axioms`).

If the user really wants to run it, they can use `#eval!`.

Closes #1697
2024-07-23 15:26:56 +00:00
Kyle Miller
d39b0415f0
feat: enable pp.fieldNotation.generalized globally (#3744)
Sets the default value to `pp.fieldNotation.generalized` to `true`.
Updates tests, and fixes some minor flaws in the implementation of the
generalized field notation pretty printer.

Now generalized field notation won't be used for any function that has a
`motive` argument. This is intended to prevent recursors from pretty
printing using it as (1) recursors are more like control flow structures
than actual functions and (2) generalized field notation tends to cause
elaboration problems for recursors.

Note: be sure functions that have an `@[app_unexpander]` use
`@[pp_nodot]` if applicable. For example, `List.toArray` needs
`@[pp_nodot]` to ensure the unexpander prints it using `#[...]`
notation.
2024-03-23 02:38:09 +00:00
Leonardo de Moura
40c8db7494 feat: improve argument type mismatch error position, and do not stop at application type mismatch errors 2022-04-25 16:30:40 -07:00
Leonardo de Moura
da55789c26 feat: add a proper BEq instance for Nat 2022-03-01 09:01:08 -08:00
Leonardo de Moura
b28f92a9ea feat: improve error message produced by #eval command when it fails to synthesize "eval" instance
closes #765
2021-11-05 15:03:57 -07:00
Leonardo de Moura
5d3f0606d2 feat: include type of type in "mismatch errors"
@Kha we do that in Lean 3. It helps when the error is due to incorrect universe levels.

BTW, I had to update `tests/lean/server/content_diag.json` since the
error message is different, but a few other stuff changed too.
Could you please take a look whether the test is still correct?
2021-03-08 09:30:34 -08:00
Sebastian Ullrich
b2b78eb222 test: use printMessageEndPos for leantests 2021-01-15 16:27:59 +01:00
Leonardo de Moura
c7ae8354fd feat: improve type mismatch error messages
Use heuristic to automatically annotate terms with `pp.explicit`.
2020-12-17 07:11:52 -08:00
Leonardo de Moura
898a08a0c1 chore: avoid Has prefix in type classes
closes #203
2020-10-27 18:29:19 -07:00
Leonardo de Moura
79609938a8 feat: allow universe constraints to be postponed longer
Before this commit, each `isDefEq u v` invocation would fail if there
were pending universe level constraints. This commit, moves the
postponed universe constraints back to the `MetaM` state.
It also adds the combinator
```lean
withoutPostponingUniverseConstraints x
```
which executes `x` and throws an error if there are pending universe
constraints. We use the combinator at `elabApp` and `elabBinders`.
Without this commit, we would fail to elaborate simple terms such as
```lean
  Functor.map Prod.fst (x s)
```
because after elaborating `Prod.fst` and trying to ensure its type
match the expected one, we would be stuck at the universe constraint:
```
  u =?= max u ?v
```

Another benefit of the new approach is better error messages. Instead
of getting a mysterious type mismatch constraint, we get a list of
universe contraints the system is stuck at.

cc @Kha
2020-10-26 15:50:05 -07:00
Leonardo de Moura
760b658d19 chore: suppress extraMsg in type mismatch errors 2020-10-06 10:58:50 -07:00
Leonardo de Moura
a6063a5560 chore: fix tests 2020-10-05 11:28:52 -07:00
Sebastian Ullrich
3834a89cdc feat: activate new pretty printer 2020-09-17 08:12:28 -07:00
Sebastian Ullrich
897f277a3e test: strip mvar suffixes 2020-09-15 09:32:00 -07:00
Leonardo de Moura
5da7f0b50b fix: set constApprox := false at SynthInstance
We don't want contraints such as
```
?m a =?= Nat
```
to be solved as
```
?m := fun a => Nat
```
durint type class resolution.
2020-09-13 16:11:27 -07:00
Leonardo de Moura
32e26799ed chore: move more tests to new frontend 2020-09-13 13:28:12 -07:00
Leonardo de Moura
82780be144 chore: fix tests 2020-06-17 21:28:37 -07:00
Leonardo de Moura
8bacf54b6c chore: fix test 2020-02-24 21:03:40 -08:00
Leonardo de Moura
a1aac9a98d chore: fix tests 2019-12-15 18:34:13 -08:00
Leonardo de Moura
a5cf1ac5ae chore: fix tests 2019-11-26 18:07:13 -08:00
Leonardo de Moura
6d358a5dee test: add test to demonstrate why it is useful to include instances in the PersistentHashMap type 2019-11-08 08:28:31 -08:00