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`.
We need this improvement to be able to finish Section "Other goodies" described at
https://github.com/leanprover/lean/wiki/Refactoring-structures
Before this commit, Lean would not be able to solve constraints such as
```lean
@has_add.add nat nat.has_add a b =?= @had_add.add ?A ?inst a b
```
The problem is that projections were being reduced eagerly, and the
constraint would be reduced to
```lean
nat.add a b =?= @had_add.add ?A ?inst a b
```
The new test proj_uniy.lean contains similar unification problems.
After this commit, `(+)` is notation for (add) instead of `(fun x y, add x y)`.
This change is relevant when defining type class instances such as
```lean
instance semigroup_to_is_associative [semigroup α] : is_associative α (*) :=
⟨mul_assoc⟩
```
Motivation: see "Other goodies" section at
https://github.com/leanprover/lean/wiki/Refactoring-structures
We had to add a new transparency mode: Instances at type_context.
In this mode, instances and reducible definitions are considered
transparent.
The new mode is used in the defeq_canonizer, code generator,
and sizeof lemma generation at inductive_compiler.
We also use the new mode in the unfold tactics.
@leodemoura The forced zeta-expansion in mk_aux_definition might
cause problems if we use tactic.abstract without zeta-reduction.
However, we never use the non-zeta mode, and it already fails right now
if you accidentally use zeta-expansion in the proof we want to abstract.
