This suggestion has been discussed at Slack.
We have decided to use #"c" as notation because we wanted to allow `'`
in the beginning of identifiers like in SML and F*. In particular,
we wanted to allow users to use 'a 'b 'c for naming type parameters
like in SML. However, nobody used this notation. In the Lean standard
library, we are using greek letters for naming type parameters.
So, there is no real motivation for the ugly #"c" syntax.
See Section "Other goodies" at
https://github.com/leanprover/lean/wiki/Refactoring-structures
This commit also improves the support for projections in the
unifier/matcher.
Now, we consider the extra case-split for projections.
Given a projection `proj`, and the constraint `proj s =?= proj t`, we need to try first `s =?= t` and if it fails, then try to reduce.
This is needed in the standard library because we now have constraints such as:
```
@has_le.le ?A ?s ?a ?b =?= @has_le.le nat nat.has_add x y
```
If we reduce the right hand side, we get the unsolvable constraint
```
@has_le.le ?A ?s ?a ?b =?= nat.le x y
```
Before this change, the constraint was `@le ?A ?s ?a ?b =?= @le nat nat.has_add x y`, and we already perform a case-split in this case.
Moreover, projections were eagerly reduced whenever possible.
The extra case-split generates a performance problem in several tests. For example `fib 8 = 34` was timing out.
I worked around this issue by performing the case-split only when the constraint contains meta-variables.
There are also minor issues. Example. `<` is notation for `has_lt.lt`, but `>` is for `gt`.
@johoelzl I'm using `abstract` tactic because instances are
automatically marked as [reducible], and they will be unfolded when
solving unification constraints. This cannot be avoided since we need to
solve unification constraints such as
int.has_add =?= comm_ring.to_has_add int.comm_ring
The `abstract tac` tactic creates an auxiliary lemma to store the proof
generated by `tac`. If we use `print int.comm_ring` we can see that
the definition is much smaller. The proofs are irrelevant. So, this has
no drawbacks, and gives us a good performance boost.
Remark: The kernel was already using Sort. So, the limitation was
artificial. Moreover, it may seem unnecessary to have quotients of
proofs in a proof irrelevant system, but this is useful for proving
a more general funext lemma. This more general version is needed in
the new tested contributed by @digama0.
