I don't have any objection to what you just stated but I'm not seeing how it addresses my question. Consider the following[](p => []q) (1)This is saying that for every state, if p holds then henceforth in every state q must hold. By the same reasoning, I don't see why you can't have an "action oriented" version of this[] [A => [][B]_vars]_vars (2)
which would read "for every step, if A holds of that step then henceforth B in every step or UNCHANGED vars must hold, or UNCHANGED vars". I hope that conveys my question a little better.thanksOn Friday, April 23, 2021 at 6:20:26 PM UTC-7 andrew...@xxxxxxxxx wrote:The logical formula in your action property must be true or false of a pair of states. The []F temporal operator is true or false of an infinite series of states.AndrewOn Friday, April 23, 2021 at 3:38:28 PM UTC-4 ns wrote:If I have a property of the form[][A => (p /\ [] (q => r))]_vars (1)where A is an action and p,q,r are state predicates, I get two complaints:Level error in applying operator $SquareAct:The level of argument 1 exceeds the maximum level allowed by the operator.and=> has both temporal formula and action as arguments.If I remove the nested [] then both complaints go away (and TLC is fine with too)[][A => (p /\ (q => r))]_vars (2)However, even if I replace the A with another state predicate the second complaint still remains.Could someone tell me where I'm going wrong. I don't recall seeing any restriction on nesting of temporal operators in the Specifying Systems book but I could have quite easily missed it. Regarding why TLC accepts the second formula (2), I assume its "nice" because its considered a Box-Action formula?thanks