@Kha I am reverting this change for now.
I understand that the "default-value" approach is bad for debugging,
and it does not produce good error messages, but at least the frontend
will not "panic" when users add a bad macro.
After we switch to the new frontend, we can have a monadic `getArg`
and `getArgs` in the Elab and Macro monads which produces an
"unexpected syntax" error message. I say we wait for the new frontend
because we will be able to write `(<- s.getArg)` inside of
expressions.
@Kha I had to do this because of the `ident` vs `Term.id` recurrent
issue. `match_syntax` fails if a `Term.id` is used at `Term.letIdDecl`
where an `ident` is expected.
We should try to remove `Term.id` in the future.
@Kha The `Name` (tactic name) approach used in Lean3 is not suitable
for Lean4. The issue is that we define tactics using macros, and in
most cases, the user doesn't even know the node id.
@Kha Patterns with nested "choice" nodes produce counterintuitive
behavior, and hard to understand errors. They only work when we have
the exact same overloads at macro definition and application time.
Here is a funky example
```
syntax [myAdd] term "++":65 term:65 : term -- overloads "++"
/- The following `macro_rules` manages to eliminate "choice" node by using the
explicitly provided node kind. -/
macro_rules [myAdd] `($a ++ $b) => `($a + $b)
check (1:Nat) ++ 2 -- works as expected
syntax "FOO!" term : term
/- Before this commit, the following pattern was accepted,
and it contained a "choice" node for `++`. It is a `myAdd` or
`HasAppend.append`.
Now, this kind of pattern is rejected since it contains a nested
"choice" -/
macro_rules `(FOO! $a ++ $b) => `($a ++ $b)
/- Before this commit, the following command worked because
it contained a "choice" node similar to the one at macro definition
time. -/
check FOO! [1, 2] ++ [2, 3]
-- Now, we have 3 overloads for "++".
syntax [myAppend] term "++":65 term:65 : term
-- The `macro_rules` fails here.
```
This commit fixes this weird behavior by disallowing "choice" nodes in
patterns.
@Kha I am adding this kind of feature to improve the user experience.
For example, the macro
```
syntax "[" ident "↦" term "]" : term
macro_rules
| `([$x ↦ $v]) => `(fun $x => $v)
```
is accepted and looks perfectly reasonable.
However, before this commit, we would get a nasty error when
elaborating
```lean
check [x ↦ x + 1]
```
