Closed langston-barrett closed 7 years ago
Notation are indeed irrelevant for Coq's logic and tactic machinery. Coq's first step is to turn notations into actual objects. You can see those actual objects by doing "Set Printing All." (or View -> Display all low level content in CoqIDE). In particular c . v
is parsed (@scalar_mult K V sm c v)
. So, the real problem that you are witnessing is that Coq's typeclass-inference/unification behaves differently when using (@scalar_mult K V sm c v)
vs sm c v
, even though the former computes to the latter. I think that for efficiency, typeclass-inference/unification is not designed to fully explore those computational equivalences (aka definitional equalities).
By consistently using only (.)
everywhere, you are reducing the need for Coq's inference mechanism to compute to be able to unify things.
Nevertheless, there will be cases where despite all those tricks, the inference mechanism will fail.
However, when apply/rewrite fails, you can help typeclass inference by manually providing some of the typeclass instances. If you read all of [1], you will see that typeclass instances are just implicit arguments that you can manually provide.
For example, you can do rewrite (@closed_under_sm _ _ _ _ _ _ _ xxx)
.
To see the types of xxx
and the dashes, do Check @closed_under_sm
.
[1] : http://www.labri.fr/perso/casteran/CoqArt/TypeClassesTut/typeclassestut.pdf
@aa755 I have read the tutorial, it's very good 😄 I guess I was just confused about the fact that/why the unifier wouldn't explore all definitional equalities. Thanks for clarifying!
I recently encountered an issue on the following lemma:
I found that if I changed the instance of
Proper
for scalar multiplication to use the dot (·
) notation and the statement of the lemma to the following, this proof worked exactly as expected:I encountered a similar error with this lemma:
But if I changed the
closure
condition to use the dot notation, everything proceeded just fine.My expectation would be that the notation should be irrelevant in proofs. Is there a good reason that it is not? Is this a bug, or are my expectations not in line with typeclass functionality?
For a little more context, see my question on StackOverflow.