08169c5ac2
Daniel is correct when he says the interaction between choice case-splits, delta case-splits, and coercions can be subtle. I believe the following condition https://github.com/leanprover/lean/blob/master/src/frontends/lean/elaborator.cpp#L111 reduces counter-intuitive behavior. Example, the coercion should not influence the resulting type. BTW, by removing this condition, many files in the library broke when I tried to compile from scratch make clean-olean make I used the following workaround. Given a delta-delta constraint f a =?= f b If the terms are types, and no case-split will be performed, then the delta-delta constraint is eagerly solved. In principle, we don't need the condition that the terms are types. However, many files break if we remove it. The problem is that many files in the standard library are abusing the higher-order unification procedure. The elaboration problems are quite tricky to solve. I use the extra condition "the terms are types" because usually if they are, "f" is morally injective, and we don't really want to unfold it. Note that the following two cases do not work check '{1, 2, 3} check insert 1 (insert 2 (insert 3 empty)) Well, they work if we the num namespace is open, and they are interpreted as having type (finset num)
21 lines
375 B
Text
21 lines
375 B
Text
import algebra.ring data.finset
|
|
open finset nat algebra
|
|
|
|
constant A : Type₁
|
|
constants a b : A
|
|
axiom decA : decidable_eq A
|
|
attribute decA [instance]
|
|
notation 5 := a
|
|
notation 5 := b
|
|
|
|
definition foo1 : finset nat :=
|
|
'{ 1, 2, 5, 5 }
|
|
|
|
definition foo2 : finset nat :=
|
|
'{ 1, 2, 3 }
|
|
|
|
definition foo3 : finset nat :=
|
|
'{ 1 }
|
|
|
|
noncomputable definition foo4 : finset A :=
|
|
'{ 5, 5, b }
|