[isabelle] Simplifier fails when dealing with mix of Pure and HOL terms

Manuel Eberl manuel at pruvisto.org
Fri Nov 28 16:36:16 CET 2025


Unless I am very mistaken, it's fairly clear that the superficial issue 
is that Quantifier1.rearrange_all sets up a goal and then tries to prove 
it with the tactic "prove_one_point_All_tac", which fails. The code is 
written in such a way that this is expected to never fail. But it does.

As for the root issue causing this failure, looked at the code in some 
detail and strongly suspect that the tactic relies on being able to 
atomize the entire goal, i.e. convert any meta-logical operators or 
quantifiers into their HOL equivalents. Once you have something in your 
goal that cannot be atomised (like your "PROP P"), this of course fails.

Some evidence that this is the case: You can trigger the same behaviour 
by putting a "PROP U" in the goal:

> lemma ‹⋀x. (x = y) ∧ z ⟹ PROP U›
>   apply simp

My impression is that the simplifier setup for the HOL session is simply 
somewhat brittle in the presence of things that cannot be atomised. 
Whether that is intended or not I cannot say. Given the prevalence of 
the "simproc del" invocations in the distribution and AFP, it seems that 
it is a known issue and that it does cause problems in real-life 
situations. So I would say it is at the very least not ideal and one 
should do something about it.

The easiest and best way would probably be to simply declare goals that 
cannot be atomised as out of scope for the simproc and make it fail 
gracefully in such cases rather than have such a spectacular crash (as I 
think Larry suggested). On one hand, I for one don't see how this could 
introduce any problems (but I am aware that saying this is tempting 
fate). On the other hand, I don't think it is an urgent issue and can 
probably wait until after the release.

Incidentally, Florian Haftmann touched this code a few years ago, so 
perhaps he can provide some further insights.

Cheers,

Manuel



On 28/11/2025 16:02, Becker, Hanno wrote:
> Thank you, all!
>
> Larry, can you explain how this relates to the presence of a `PROP P` term in the goal? Is the simproc somewhere expecting to find all premises of the form `HOL.Trueprop ...`?
>
> Best,
> Hanno
>
> On 28/11/2025, 14:51, "Lawrence Paulson" <lp15 at cam.ac.uk <mailto:lp15 at cam.ac.uk>> wrote:
>
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
>
>
>
> I think the exception is coming from a low-level function called yield_singleton, which is called by the version of prove_conv in Provers/quantifier1.ML. Several of the simprocs there contain the snippet
>
>
> SOME (prove_conv ctxt …)
>
>
> and each of these could raise exception List.Empty, which would not be caught and would blow up at the top level.
>
>
> So if it is not too late, I propose adding an exception handler to each
>
>
> handle List.Empty => NONE.
>
>
> Larry
>
>
>> On 28 Nov 2025, at 11:00, Manuel Eberl <manuel at pruvisto.org <mailto:manuel at pruvisto.org>> wrote:
>>
>> This doesn't look like intended behaviour to me. I tracked the problem to the "defined_all" simproc, specifically to the ML function "Quantifier1.rearrange_all". If you remove that simproc from the simpset, the exception does not occur.
>>
>> Perhaps this helps somebody who knows that part of the code understand what is going on.
>>
>
>
>
>


More information about the isabelle-dev mailing list