Documentation

Guarded2Network.Lemmas.Seq

What the sequence expressions Guarded2Network builds over inbox mean.

Core/ComputableTLAPlus/Semantics/Interface.lean keeps the expression layer abstract: Eval is a relation with no axioms about any particular operator, and the only sequence facts it carries are value-level (seqAppend, isSeq). That is deliberate — Core's semantics has no business naming TLA⁺'s Sequences module. But this pass compiles a receive into Head/Tail/Len calls over inbox (Guarded2Network.head/.tail/.lenGt), so its refinement proof has to know that Head(inbox) denotes the first element of what inbox holds — a fact about those expressions, not about Eval in general.

So the laws live here, in a class the refinement theorems take instance-implicit, and the split is: ExprSemantics says what a sequence value is, SeqBuiltins says what this pass's sequence expressions evaluate to. A concrete TLA⁺ evaluator will satisfy both; nothing in Core/ has to mention Head to state either.

Each law is an against the expression's shape rather than a one-directional evaluation rule, because the proof needs both readings: forwards to compute the target's guard from the source's channel contents, backwards to rule out a target step the source cannot match.

The meaning of Guarded2Network's own sequence expressions, on top of ExprSemantics's value-level sequence vocabulary.

Instances

    The three laws at the one argument the pass ever passes them #

    Every call site builds its sequence expression over the variable inbox, so each law arrives with its inner Eval already determined by a memory lookup. Specialising once here keeps ExprSemantics.evalVar and isSeq_inj out of the refinement proofs, which is otherwise the same four lines at every use.

    Head(inbox) denotes the first element inbox holds, and only that. Note the hypothesis has the sequence non-empty: on an empty inbox the law gives no value at all, which is what makes the compiled guard block rather than abort.