# Re: [isabelle] rule is sometimes very slow

```On Tue, 2 Dec 2014, Lars Noschinski wrote:

```
```theory Scratch imports Main
begin

abbreviation funswapid :: "'a ⇒ 'a ⇒ 'a ⇒ 'a" (infix "⇌⇩F" 90) where
"x ⇌⇩F y ≡ Fun.swap x y id"

fix uv uw vu vw wu wv f GM HM m n a
assume "(vw ⇌⇩F vu ∘ f HM ^^ Suc m ∘ (uw ⇌⇩F uv ∘ vw ⇌⇩F vu)) a = (f
GM ^^ Suc n) a"
then have "∃m. (vw ⇌⇩F vu ∘ f HM ^^ Suc m ∘ (uw ⇌⇩F uv ∘ vw ⇌⇩F vu)) a
= (f GM ^^ Suc n) a"
by (rule exI)
end

The proof step "rule exI" takes several seconds to complete on my
machine (in Isabelle 2014). Similar proofs, like

by (rule_tac exI)
by -  (rule exI)
by - (erule exI)
by metis
by blast

are instantaneous, as expected. I looked a bit into the implementation
of rule and it seems that most time is spend
in evaluating the result of

Drule.multi_resolves facts @{thms exI}
```
```
```
Drule.multi_resolves is not relevant here, it is merely a wrapper for Thm.biresolution, i.e. the main rule composition principle of Isabelle/Pure.
```

The key difference of the structured form

then have "∃m. P m" by (rule exI)

```
compared to the other ones above is the order of higher-order unification attempts. The 'then' means that some fact is unified with the premise of exI, which is the worst-case situation ?P ?x and thus can go amiss.
```
```
Only in the second stage, the closed conclusion ∃. P m contributes more specific unification constraints.
```

```
This problem has been there in Isar proofs since 1998/1999, and until today I don't know a better way. The HO-unification code of Isabelle is ultimately a mystery to me.
```

Makarius

----------------------------------------------------------------------------
http://stop-ttip.org  1,070,319 people so far
----------------------------------------------------------------------------```

This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.