bd46319aee
Where before we had ```lean #check fun x : Nat => ?a -- fun x ↦ ?m.7 x : (x : Nat) → ?m.6 x ``` Now by default we have ```lean #check fun x : Nat => ?a -- fun x => ?a : (x : Nat) → ?m.6 x ``` In particular, delayed assignment metavariables such as `?m.7` pretty print using the name of the metavariable they are delayed assigned to, suppressing the bound variables used in the delayed assignment (hence `?a` rather than `?a x`). Hovering over `?a` shows `?m.7 x`. The benefit is that users can see the user-provided name in local contexts. A justification for this pretty printing choice is that `?m.7 x` is supposed to stand for `?a`, and furthermore it is just as opaque to assignment in defeq as `?a` is (however, when synthetic opaque metavariables are made assignable, delayed assignments can be a little less assignable than true synthetic opaque metavariables). The original pretty printing behavior can be recovered using `set_option pp.mvars.delayed true`. This PR also extends the documentation for holes and synthetic holes, with some technical details about what delayed assignments are. This likely should be moved to the reference manual, but for now it is included in this docstring. (This PR is a simplified version of #3494, which has a round-trippable notation for delayed assignments. The pretty printing in this PR is unlikely to round trip, but it is better than the current situation, which is that delayed assignment metavariables never round trip, and plus it does not require introducing a new notation.)
33 lines
1.2 KiB
Text
33 lines
1.2 KiB
Text
mulcommErrorMessage.lean:8:13-13:25: error: type mismatch
|
|
fun a b => ?m
|
|
has type
|
|
(a : ?m) → (b : ?m a) → ?m a b : Sort (imax ?u ?u ?u)
|
|
but is expected to have type
|
|
a✝ * b✝ = b✝ * a✝ : Prop
|
|
the following variables have been introduced by the implicit lambda feature
|
|
a✝ : Bool
|
|
b✝ : Bool
|
|
you can disable implicit lambdas using `@` or writing a lambda expression with `{}` or `[]` binder annotations.
|
|
mulcommErrorMessage.lean:11:22-11:25: error: type mismatch
|
|
rfl
|
|
has type
|
|
true = true : Prop
|
|
but is expected to have type
|
|
true = false : Prop
|
|
mulcommErrorMessage.lean:12:22-12:25: error: type mismatch
|
|
rfl
|
|
has type
|
|
false = false : Prop
|
|
but is expected to have type
|
|
false = true : Prop
|
|
mulcommErrorMessage.lean:16:3-17:47: error: type mismatch
|
|
fun a b => ?m
|
|
has type
|
|
(a : ?m) → (b : ?m a) → ?m a b : Sort (imax ?u ?u ?u)
|
|
but is expected to have type
|
|
a✝ * b✝ = b✝ * a✝ : Prop
|
|
the following variables have been introduced by the implicit lambda feature
|
|
a✝ : Bool
|
|
b✝ : Bool
|
|
you can disable implicit lambdas using `@` or writing a lambda expression with `{}` or `[]` binder annotations.
|
|
mulcommErrorMessage.lean:16:12-17:47: error: failed to elaborate eliminator, expected type is not available
|