@Kha Before this commit, we were producing the error "expected command" at the `let` token
```lean
check id let x := 1; x
```
The new error is "expected command, but found term; this error may be
due to parsing precedence levels, consider parenthesizing the term".
The example above looks artificial, but it will happen all the time as
users start to define their own notation.
@Kha This one is not as useful as the indented `do`. When writing
interactive proofs I like the error message at the `}` showing the
resulting tactic state. We can simulate it using a `skip` in the end of the sequence :)
We remove the `skip` when the proof is done. Note that, the last `;`
is usually not part of the `by`. Example:
```lean
theorem ex (x y z : Nat) : y = z → y = x → x = z :=
fun _ _ =>
have x = y by apply Eq.symm; assumption; -- <<< the last `;` is part of the `have`
Eq.trans this (by assumption)
```
@Kha it now uses the same precedence of `fun`.
The main motivation is to allow us to write `@by { ... }` instead of
`@(by { ... })`.
BTW, I am considering disabling implicit lambdas for `by ...` expressions.
It is automatically "intro"ducing the implicit variables without
giving an opportunity for users to pick their names.
Note that `?_` is not equivalent to `_`. Both do not have a name, but
`?_` is a synthetic metavariable which **cannot** be assigned by typing
constraints, and `_` is a regular metavariable.
We use `?_` to mark an anonymous hole that must be filled using tactics.
@Kha I will rename `namedHole` to `syntheticHole`
```lean
match x : t with
| ...
```
Two possible intepretations for `x : t`:
1- The discriminant `t` where `x` is the name for the equality proofs `t = ...` in each alternative.
2- The discriminant `x` with a expected type `t` (aka motive) for the match.
This commit resolves the ambiguity by forcing no space before `:` in
the first interpretation.
cc @Kha
