@Kha `withReader` is a well-behaved version of `adaptReader`. `adaptReader` is
too general, and it often produces counterintuitive elaboration
errors.
Here are two super annoying issues I hit all the time:
1- `adaptReader` + polymorphic code
```
def ex1 : ReaderT Nat IO Unit :=
adaptReader (fun x => x + 1) $
IO.println "foo" -- 3 Errors here failed to synthesize `Monad ?m` and `MonadIO ?m`, and don't know how to synthesize `Type → Type`
```
2- `adaptReader` and notation that requires the expected type
```
structure Context :=
(x y : Nat)
def ex2 : ReaderT Context IO Nat :=
adaptReader (fun s => { s with x := 10 }) $ -- Error at the structure instance
...
```
In the example above, I have to write `fun (s : Context) => ...` to
fix the problem.
The two problems above happen in the old and new frontends. However,
there is a new problem specific for the new frontend. In the new
frontend, a `do` is only elaborated when the expected type is known.
So, `adaptReader (fun ctx => ...) do ...` seldom works :(
As I said above, the issue is that `adaptReader` is too general. Its
type is
```
{ρ ρ' : Type u_1} → {m m' : Type u_1 → Type u_2} → [MonadReaderAdapter ρ ρ' m m'] → {α : Type u_1} → (ρ' → ρ) → m α → m' α
```
`withReader` is a simpler version of `adaptReader`
```
withReader : {ρ : Type u_1} → {m : Type u_1 → Type u_2} → [MonadWithReader ρ m] → {α : Type u_1} → (ρ → ρ) → m α → m α
```
It doesn't have any of the problems above. Moreover, I managed to replace
every single instance of `adaptReader` with `withReader` at the stdlib
and tests. We don't need the `adaptReader` generality.
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
@Kha `hygienicIntro` is true by default. `hygienicIntro == false` is
the Lean3 behavior. If we find `hygienicIntro` too inconvenient in
practice, we set the default to false.
Versions of `introN` and `intro1` that preserve the binder name.
They are used to implement the idiom: "revert", do something, re-"intro"-tuce
Before this commit `introNP mvarId n` was `intro1 mvarId n [] false`.
It preserves the location of the local declaration.
@Kha This tactic is going to be used to fix another hygiene related bug in
Lean3 :)
Here is small repro for the problem.
```
example (m n k : ℕ) (h : 0 + n = m) (h : k = m) : ... :=
begin
-- Here `h : k = m` is accessible.
rw [nat.zero_add] at *
-- `h : k = m` is not accessible anymore, and it is a name for
-- the simplified `h : n = m` which was inaccessible before.
end
```
For example, `mkFreshExprMVar none MetavarKind.synthetic` should
create a fresh synthetic metavariable `?m` with type `?t` where `?t`
is a fresh natural metavariable. If users want a synthetic
metavariable `?t`, then it must create it themselves.
@Kha I am also tracking `currNamespace` and `openDecls`.
BTW, I also tried an experiment where I added `currNamespace` and
`openDecls` to `Meta.Context`, but it looked weird. This information
is only needed in the elaborator and pretty printer.
The `PPContext` object should contain everything you need. You
can put `currNamespace` and `openDecls` in the `Delaborator.Context`.
The idea is to make clear that the field `posponed` is transient
state. It is only used during `isDefEq`.
The refactoring was motivated by a bug I found where the `posponed`
constraints were not being handled correctly. For example,
the `check (e : Expr)` method was returning `true`, but leaving pending
universe constraints at `postponed`.
cc @Kha
