Convert two instances of has_zero and has_one to local instance,
and change one "[instance]" to a "[trans_instance]". This (by
accident) fixed a problem Rob had a couple of weeks ago.
@avigad and @fpvandoorn, I changed the metaclasses names. They
were not uniform:
- The plural was used in some cases (e.g., [coercions]).
- In other cases a cryptic name was used (e.g., [brs]).
Now, I tried to use the attribute name as the metaclass name whenever
possible. For example, we write
definition foo [coercion] ...
definition bla [forward] ...
and
open [coercion] nat
open [forward] nat
It is easier to remember and is uniform.
Many theorems for division rings and fields have stronger versions for discrete fields, where we
assume x / 0 = 0. Before, we used primes to distinguish the versions, but that has the downside
that e.g. for rat and real, all the theorems are equally present. Now, I qualified the weaker ones
with division_ring.foo or field.foo. Maybe that is not ideal, but let's try it.
I also set implicit arguments with the following convention: an argument to a theorem should be
explicit unless it can be inferred from the other arguments and hypotheses.
These changes were needed because e.g. real.add_zero was "x + zero = x", and rewrite
would not match it to a goal "t + 0".
The fix was a lot harder than I expected. At first, migrate failed with resource
errors. In the end, what worked was this: I defined the coercion from num to real
directly (rather than infer num -> nat -> int -> rat -> real).
I still don't understand what the issues are, though. There are subtle issues with
numerals and coercions and migrate.
(We are not alone. Isabelle also suffers from the fact that there are too many
"zero"s and "one"s.)
See issue #692.
The implementation still has some rough spots.
It is not clear what the right semantic is.
Moreover, the folds in e_closure could not be eliminated automatically.
