Commit graph

38 commits

Author SHA1 Message Date
Leonardo de Moura
5249fdc24d chore: cleanup and style 2020-12-12 10:36:26 -08:00
Leonardo de Moura
7a4b544b1c feat: improve application type mismatch error message
If the type error is at an implicit argument, we annotate
application with `pp.explicit := true`

Given the type incorrect definition
```
def f {a b c : α} : a = c :=
  Eq.trans (a := a) (b := b = c)
```
We now generate the error
```
error: application type mismatch
  @Eq.trans α a (b = c)
argument
  b = c
has type
  Prop
but is expected to have type
  α
```
@Kha Note that we only enable `pp.explicit := true` for the relevant
application. That is, we set `pp.explicit := false` for each children.

Unfortunately, there is a corner case.
```
set_option pp.explicit true
def f {a b c : α} : a = c :=
  Eq.trans (a := a) (b := b = c)
```
produces the error
```
error: application type mismatch
  @Eq.trans α a (b = c)
argument
  @Eq α b c
has type
  Prop
but is expected to have type
  α
```
The reset `pp.explicit := false` overwrote the user option.
I think the simplest solution is the following
1- The delaborator saves the initial set of Options `Init`
2- When it finds a node annotated with a `pp` options, it only
consider the option if it is not set by `Init`.

What do you think?
2020-12-09 13:58:08 -08:00
Leonardo de Moura
0869f38de4 chore: update structure, class, inductive 2020-11-27 15:09:30 -08:00
Leonardo de Moura
d6f778bec4 refactor: arbitrary without explicit arguments
@Kha I was tired of writing `arbitrary _` :)
There 0 places in the stdlib where the type needs to be provided.
If in the future we need to specify the type we can use
`arbitrary (α := <type>)`
2020-11-25 09:07:38 -08:00
Leonardo de Moura
cb9574b086 chore: test unboundImplicitLocals and cleanup 2020-11-22 10:33:28 -08:00
Leonardo de Moura
8598dde6e6 fix: if-then-else elaboration issue
@Kha I hate this kind of hack, but the behavior looked unacceptabled
to me. I added a big comment describing the issue and the hack.
2020-11-21 20:51:28 -08:00
Leonardo de Moura
c305c2691f chore: use := 2020-11-19 07:22:31 -08:00
Leonardo de Moura
2daeb195b5 chore: use new names 2020-11-10 10:15:19 -08:00
Leonardo de Moura
7b5f283507 chore: remove Expr.localE constructor
It was used by the old frontend
2020-11-01 09:37:48 -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
5fed774461 chore: HasRepr ==> Repr 2020-10-27 16:15:10 -07:00
Leonardo de Moura
10c32fcf94 chore: HasToString => ToString 2020-10-27 16:11:48 -07:00
Leonardo de Moura
13c2a8ff51 chore: remove #lang lean4 header 2020-10-25 09:54:07 -07:00
Leonardo de Moura
0ab38742db chore: cleanup 2020-10-24 06:18:01 -07:00
Leonardo de Moura
af968c60e6 chore: cleanup 2020-10-22 07:32:23 -07:00
Leonardo de Moura
82ee2e361b chore: cleanup 2020-10-21 18:43:47 -07:00
Leonardo de Moura
ea829b75c0 chore: remove coercions for old frontend 2020-10-21 17:37:35 -07:00
Leonardo de Moura
28664d9dc2 chore: move to new frontend 2020-10-20 17:41:04 -07:00
Leonardo de Moura
17836a3a6f chore: add instance for new frontend
The new frontend uses discrimination trees to filter candidates.
2020-10-19 06:37:23 -07:00
Leonardo de Moura
82e11c401d fix: #eval was not capturing dbgTrace! output in pure code
In the following example, the output produced by `dbgTrace!` was not
being captured. It could break the lean server. At least, it broke the lean4-mode.
```lean
def f (x : Nat) : Nat :=
dbgTrace! ">>> " ++ toString x;
x + 1

eval f 10
```

cc @Kha
2020-10-05 10:22:04 -07:00
Leonardo de Moura
0511b73d80 feat: add replaceFVars 2020-09-22 14:24:03 -07:00
Leonardo de Moura
b025c1c623 chore: remove HasEmptyc workarounds 2020-09-11 14:28:42 -07:00
Leonardo de Moura
e9f7fb45af chore: add coercion for new frontend 2020-09-11 14:00:16 -07:00
Leonardo de Moura
34291e2151 feat: add Name.simpMacroScopes
@Kha We currently have a few macros that create binder names
such as `x`. These macros rely on the hygienic framework. This part is
great. Before this commit we were simply erasing the macro
scopes when creating the actual binders at `Expr.lean`.
The result produced expressions that were hard to debug.
For example, consider the following scenario

1- Macro creates a few binder names using ``x <- `(x)``
2- We create a lambda expression `t` with these binder names.
3- Then, we use `lambdaTelescope t fun xs body => ...`
   Now, if we trace `xs` and `body`, we get `#[x, x, ... x]` and
   we can't distinguish the different `x`s in `body`.
   So, it is really hard to debug anything using the traces.

This commit adds `Name.simpMacroScopes` for simplying "macro scoped"
names. Example: given `x._@.Init.Data.List.Basic._hyg.2.5`, it
produces `x.2.5`. I exported this function, and used it in the old
pretty printer.

I have considered modifying `lambdaTelescope` to make sure it creates
unused names. I think this option is bad because it introduces
overhead, and in a few places we want to preserve the binder names.

I have also considered replacing the `let x := x.eraseMacroScopes` at
`Expr.lean` with `let x := x.simpMacroScopes`. I think this option is
bad since we are destroying scoping information and will not be able
to distiguish which variables have macro scopes when processing
tactics.

Anyway, the solution in this commit is good for this week, but we
should discuss a more permanent solution next week.
2020-09-08 18:22:44 -07:00
Leonardo de Moura
296981319c feat: add abstractNestedProofs 2020-09-08 11:48:28 -07:00
Leonardo de Moura
6fc935f6d1 refactor: add MonadNameGenerator 2020-08-23 19:56:01 -07:00
Leonardo de Moura
24025b96c5 feat: elaborate equation RHS 2020-08-13 15:19:40 -07:00
Leonardo de Moura
aaf5034ba2 chore: add helper 2020-08-13 14:14:21 -07:00
Leonardo de Moura
08f1c2310b chore: enforce naming convention 2020-08-13 14:09:00 -07:00
Leonardo de Moura
5b1b11ffe0 feat: add isCharLit 2020-08-13 13:15:15 -07:00
Leonardo de Moura
e43b5e27a1 feat: add processComplete 2020-08-03 17:02:53 -07:00
Leonardo de Moura
33d4732e58 fix: processVariable bug 2020-08-03 12:33:19 -07:00
Leonardo de Moura
98e9fc20d5 feat: add replaceFVar 2020-07-30 13:06:45 -07:00
Leonardo de Moura
18fce4f455 feat: add Expr.inferImplicit 2020-07-13 16:22:48 -07:00
Leonardo de Moura
1612097788 chore: move HashMap and HashSet to Std 2020-06-25 12:46:56 -07:00
Leonardo de Moura
1be221a1f4 chore: move PersistentHashMap and PersistentHashSet to Std 2020-06-25 11:56:00 -07:00
Leonardo de Moura
249bda16c0 chore: remove prelude commands from Lean package 2020-06-25 11:21:17 -07:00
Leonardo de Moura
4ccc3fef52 chore: move Init.Lean files to Lean package 2020-05-26 15:04:35 -07:00
Renamed from src/Init/Lean/Expr.lean (Browse further)