[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*From*: Stephan Merz <stephan.merz@xxxxxxxxx>*Date*: Sat, 25 Nov 2023 09:51:57 +0100*References*: <0d5368ca-6221-404a-a144-362e874a1431n@googlegroups.com>

Hi Ramon, thank you for your question and indeed, documentation for the more recent features of the prover is sorely lacking. The only examples using the ENABLED backends that I am aware of are - module SimpleExampleWF in the examples_draft directory of the tlapm repository (https://github.com/tlaplus/tlapm/tree/main/examples_draft) - the termination proof of the termination detection algorithm described in EWD998 at https://github.com/tlaplus/Examples/blob/master/specifications/ewd998/EWD998_proof.tla (that proof uses some features beyond the elementary ExpandENABLED primitive) In order to answer your question, the PTL backend is not based on axioms but on a decision procedure for propositional temporal logic. The details are described in our "coalescing" paper [1]. This has two fundamental consequences: 1. In first approximation, PTL does not handle sequents (ASSUME / PROOF constructs), except for constant-level assumptions [2]. I recommend only invoking it in such contexts. The "non-[]" warnings that you see in the proof output are an indication of this: they tell you that these ASSUME / PROOF steps should be rewritten as plain implications. 2. PTL only handles propositions and does not perform even trivial first-order reasoning. It will abstract atomic formulas such as `x = "red"' into a proposition, but sometimes it may be helpful to introduce propositional abstractions yourself, and it won't know that trivialities such as x = "red" => ~(x = "blue") holds. (I believe it doesn't even know that `x # "red"' is equivalent to `~(x = "red")'.) Below is your proof rewritten with these caveats in mind, and an outline of your "main" theorem whose QED step is checked by PTL. Note in particular that it is really necessary in that proof to write <1>1. Spec => []((x = "red") => <>(~(x = "red") /\ (x = "blue"))) due to observation (2) above, otherwise PTL won't know that the step from red to blue cannot just be a stuttering step. The missing proofs for steps <1>1 to <1>3 should be similar to the proof of your lemma that x will eventually be blue. (I'd actually recommend setting up the lemma in the way that it fits the steps required in the main proof so that you can use lemmas there.) In the proof of your first real liveness theorem, besides rewriting ASSUME / PROOF to implications I also had to add the step <1>4. Init /\ [Next]_x => Init' \/ (x = "blue")' BY DEF Init, Next Without it, the conclusion wouldn't hold: weak fairness ensures that a <<Next>>_x transition will be taken only if it remains enabled, not if it just happens to be enabled at some point. Besides, I made a few cosmetic changes to your proofs, in particular by reformulating the type-correctness lemma so that it can be used within the liveness proof. I do hope this helps you to make progress: feel free to come back with further questions that will invariably arise. Best, Stephan [1] https://members.loria.fr/SMerz/papers/arqnl2014.html [2] More generally, all assumptions of lemmas should be "boxed" formulas, i.e., trivially equivalent to []F for some F. --------------------------- MODULE RingEventually --------------------------- EXTENDS TLAPS VARIABLE x Init == x = "red" Next == \/ (x = "red" /\ x' = "blue") \/ (x = "blue" /\ x' = "green") \/ (x = "green" /\ x' = "blue") Spec == Init /\ [][Next]_x /\ WF_x(Next) TypeOK == x \in {"red", "green", "blue"} LEMMA TypeSafety == Init /\ [][Next]_x => []TypeOK PROOF <1> USE DEF TypeOK <1>1. Init => TypeOK BY DEF Init <1>2. ASSUME TypeOK /\ [Next]_x PROVE TypeOK' BY <1>2 DEF Next <1> QED BY <1>1, <1>2, PTL DEF Spec LEMMA EventuallyRed == Spec => <>(x = "red") PROOF BY PTL DEF Spec, Init THEOREM Spec => <>(x = "blue") PROOF <1>2. TypeOK /\ Init => ENABLED <<Next>>_x BY ExpandENABLED DEF Init, Next <1>3. Init /\ <<Next>>_x => (x = "blue")' BY DEF Init, Next <1>4. Init /\ [Next]_x => Init' \/ (x = "blue")' BY DEF Init, Next <1> QED BY <1>2, <1>3, <1>4, TypeSafety, PTL DEF Spec \* And my actual goal: how should _this_ proof be structured? THEOREM Spec => []<>(x = "red") <1>1. Spec => []((x = "red") => <>(~(x = "red") /\ (x = "blue"))) <1>2. Spec => []((x = "blue") => <>(~(x = "blue") /\ (x = "green"))) <1>3. Spec => []((x = "green") => <>(~(x = "green") /\ (x = "red"))) <1>. QED BY <1>1, <1>2, <1>3, EventuallyRed, PTL =============================================================================
You received this message because you are subscribed to the Google Groups "tlaplus" group. To unsubscribe from this group and stop receiving emails from it, send an email to tlaplus+unsubscribe@xxxxxxxxxxxxxxxx. To view this discussion on the web visit https://groups.google.com/d/msgid/tlaplus/6883916B-8B2D-426C-90C9-E7AC3781E981%40gmail.com. |

**Follow-Ups**:**Re: [tlaplus] Proving eventualities with TLAPS (1.5.0)***From:*Ramon Snir

**References**:**[tlaplus] Proving eventualities with TLAPS (1.5.0)***From:*Ramon Snir

- Prev by Date:
**[tlaplus] Proving eventualities with TLAPS (1.5.0)** - Next by Date:
**Re: [tlaplus] Proving eventualities with TLAPS (1.5.0)** - Previous by thread:
**[tlaplus] Proving eventualities with TLAPS (1.5.0)** - Next by thread:
**Re: [tlaplus] Proving eventualities with TLAPS (1.5.0)** - Index(es):