@Kha It seems the recent parser modifications created some unexpected
problems. I didn't investigate them. I am "lost" in the elaborator and
dependent pattern matching land.
1) We can't write anymore
```
f [1, 2, 3] |>.run' 0 = Except.ok ()
```
We have to use parentheses and the error message is weird :(
```
(f [1, 2, 3] |>.run' 0) = Except.ok ()
```
2) I had to add comments to `macro.lean`, I didn't find a workaround
for one of the rules. BTW, I had to add a bunch of `:term` for fixing
the other rules, and the error messages were counterintuitive.
@Kha I marked the corresponding methods as `protected`.
I currently can't stand `throw_error`, and I am optimistic about
server highlighting feature you are working on :)
closes#341
This is another instance of a compiler bug.
It is in the code that is still written in C/C++.
We need to infer types in the compiler, and we reused the kernel type
checker for this.
However, the compiler performs transformations that may produce type
incorrect terms.
This happens in code that makes heavy use of dependent types (like the
new test).
This is just a workaround for this particular instance of the problem.
The definitive solution will only happen when we replace
this part of the compiler with Lean code, and implement a custom
`inferType` method for the compiler.
@Kha, Jason's example on issue #337 suggests that injecting
implicit-lambdas while elaborating patterns is problematic.
The elaborator was injecting `fun {Γ} =>` before the
pattern variable `ftm`.
So, I disabled the implicit-lambda during pattern elaboration. I
didn't find an example where it would be useful.
see #337
cc @JasonGross
