RFC006: Framework for unit-testing #817
Replies: 1 comment 5 replies
-
@lemmy wrote in #741 (comment):
I think it is clear to me now why I did not want to have an explicit operator like TLCExt.Trace. The issue with this approach is not only that it is hard for Apalache to carry the trace as part of the state, but also that you can define the computation of a TLA+ spec by using the computation history. A cleaner approach would be to define predicates on computations, similar to LTL, which is a special language for such predicates. (Actually, LTL is defined over infinite traces, but for the finite-state systems we are talking about finite lassos.) Here is an example of how one could specify a trace invariant: ------------------------------- MODULE TraceInv -------------------------------
EXTENDS Integers, Sequences
VARIABLE
\* @typeAlias: STATE = [x: Int];
\* @type: Int;
x
Init ==
x = 1 \/ x = -1
Next ==
x' = x + x
\* @type: Seq(STATE) => Bool;
TraceInv(hist) ==
/\ hist[1].x > 0 =>
hist[Len(hist)].x >= hist[1].x
/\ hist[1].x < 0 =>
hist[Len(hist)].x <= hist[1].x
=============================================================================== |
Beta Was this translation helpful? Give feedback.
-
RFC006 describes in detail a framework for unit-testing of TLA+ specifications. There are plenty of ideas in the PR #741, which is hard to find, unless you know about it. Let's continue the discussion in this thread.
Beta Was this translation helpful? Give feedback.
All reactions