I have the following spec:
------------------------------ MODULE Group ------------------------------
CONSTANTS People
VARIABLES members
Init == members \subseteq People
Next == members' = members
Group == Init /\ [][Next]_members
=============================================================================
(I simplified this spec to the point where it's not doing anything useful.)
When I try to run it through TLC, I get the following error:
In evaluation, the identifier members is either undefined or not an operator.
The error points to the Init line.
When I change the Init line to:
Init == members \in People
it validates fine.
I want the former functionality because I mean for members to be a collection of People, not a single person.
According to section 16.1.6 of Leslie Lamport's Specifying Systems, "TLA+ provides the following operators on sets:" and lists both \in and \subseteq.
Why is TLA+ not letting me use \subseteq?
While that is a valid TLA+ expression, TLC can only assign next-state values to a variable x by the statements x' = e or x' \in S. See section 14.2.6 for details. This holds for the initial assignment, too. In your case, you probably want members \in SUBSET People.
Related
The below module declares a set of numbers that are in the range 10 to 99 that are divisible by 2 only once and call it NumbersThatDivideBy2Once. At the end it declares a theorem that the constant input is a subset of NumbersThatDivideBy2Once.
--------------------------- MODULE TestModule ---------------------------
EXTENDS Naturals
CONSTANT input
Numbers == { n \in Nat : n > 9 /\ n < 100 }
DividesBy2(n) == (n % 2) = 0
DividesBy2Once(n) == DividesBy2(n) /\ ~DividesBy2(n \div 2)
NumbersThatDivideBy2Once == { n \in Numbers: DividesBy2Once(n) }
THEOREM input \subseteq NumbersThatDivideBy2Once
=======================
How can I check if this theorem holds for a given input? If I run a model check with a provided set of numbers as input, even if some of those numbers are not part of NumbersThatDivideBy2Once I still get no errors.
Give your theorem a name,
THEOREM T == input \subseteq NumbersThatDivideBy2Once
Go to the "Model Checking Results" tab, and in "Evaluate Constant Expression" introduce T, in order for it to be evaluated.
Your model checker needs to be told what to do with the specification file, which is essentially a just collection of mathematical definitions.
In "normal use" you want to provide TLC a temporal formula representing your specification (usually given the nameSpec in the specification file). You introduce it in the "model overview" tab, under "what is the behaviour spec?". And that is what TLC uses to perform model checking.
In this case you don't have that. So just keep the option "no behaviour spec" and, as indicated above, specify in the "Model Checking Results" tab the constant expression you want to evaluate.
I have a TLA+ module, which, summarized, looks like this:
--- MODULE Group ---
CONSTANTS People
VARIABLES members
Join(person) == ...
Leave(person) == ...
Init == members \subseteq People
Next == \E p \in People :
\/ Join(p)
\/ Leave(p)
====================
When I try to model-check this with TLC, I get the following error:
TLC threw an unexpected exception.
This was probably caused by an error in the spec or model.
See the User Output or TLC Console for clues to what happened.
The exception was a java.lang.RuntimeException
:
TLC cannot handle this conjunct of the spec:
line X, col Y to line Z, col T of module Group
...pointing to the entire content of Next.
I believe my Next is well-written, because here's an example model that has a very similar Next to mine: https://github.com/tlaplus/Examples/blob/master/specifications/aba-asyn-byz/aba_asyn_byz.tla#L110
Also, section 14.2.2 of Leslie Lamport's Specifying Systems says:
TLC can evaluate a set-valued expression only if that expression equals a finite set[...]. TLC will evaluate expressions of the following forms only if it can enumerate the set S:
and provides the example of "there exists x in S such that p".
How can I solve this error?
The problem was with my use of \subseteq in Init, as answered here: \in works, while \subseteq gives a "identifier undefined" error
I'm going through Specifying Systems right now and I'm a little puzzled about how I'd model-check the following module:
---------------------------- MODULE BoundedFIFO ----------------------------
EXTENDS Naturals, Sequences
VARIABLES in, out
CONSTANT Message, N
ASSUME (N \in Nat) /\ (N > 0)
Inner(q) == INSTANCE InnerFIFO
BNext(q) == /\ Inner(q)!Next
/\ Inner(q)!BufRcv => (Len(q) < N)
Spec == \EE q : Inner(q)!Init /\ [][BNext(q)]_<<in, out, q>>
=============================================================================
I see that both the Init and BNext formulas are operators, parameterized by q. How would I supply this to the model checker?
You can't: \E x : P(x) is an unbounded expression, which TLC cannot handle. Many of the specs in Specifying Systems can't be modeled. More recent guides, such as the TLA+ Hyperbook or Learn TLA+, are more careful to keep all of their specs modelable.
Sorry the title is a bit cryptic. I have a TLA+ spec that defines two sets:
variables Requests = {}, Outcomes = {};
I have one set of workers adding requests, and another set or workers fulfilling them and writing to Outcomes. Each request has a unique Id, which the matching Outcome entry will then also contain.
I want to guarantee that any request added to the Requests set is eventually matched by a structure with the same Id in the Outcomes set. I've been trying to do this using the "leads to", ~>, operator, but can't figure out how to resolve the Id matching portion.
I've naively tried something like:
RequestsAreFulfilled == \E req \in Requests: TRUE
~> \E outcome \in Outcomes : outcome.id = req.id
But this obviously breaks since req is not defined in the second expression. I've considered something along the lines of the second express being "Then there is a state where all Request items are matched by Outcome items", but that doesn't work since the system never terminates - there may very well always be more requests in the Requests set, since Outcomes is always playing catch-up.
What is a way for me to assert that a request is eventually matched with an outcome with the same id?
TLC has some trouble proving liveness properties with nonconstant sets. Let's start with the fixed case, where you have a finite, fixed set of ids. Then we can specify the relation as
\A id \in Ids: (\E r \in req: r.id = id) ~> (\E o \in out: o.id = id)
In this case, though, we're better off using structures, as they're easier to understand and express shared relationships better.
requested = [i \in Ids |-> FALSE];
processed = [i \in Ids |-> FALSE];
\A id \in Ids: requested[i] ~> processed[i]
or
messages = [i \in Ids |-> [requested |-> FALSE, processed |-> FALSE]]
\A id \in Ids:
LET m == messages[i]
IN m.requested ~> m.processed
If you want an infinite number of messages, one way to get TLC to handle liveness checks is to use a fixed set of ids then add logic to "recycle" finished messages - set both requested and processed to FALSE. Then we can use the always-eventually operator, []<>, to express this:
\A id \in Ids: []<>(requested[i] => processed[i])
Disclaimer: this is for a homework assignment
I'm a coq noob, so I hope this is not a repeat question. I /have/ looked at this question, but my question seems to be unanswered still.
I have the following premises:
P \/ Q
~Q
I need to prove:
P
My coq code so far:
Section Q5.
Variables Q : Prop.
Goal P.
Hypothesis premise1 : P \/ Q.
Hypothesis premise2 : ~Q.
I get the following error when I try to execute the line Goal P.:
Error: The reference P was not found in the current environment.
These are the solutions that I was able to come up with:
Replace Variables Q : Prop. with Variables P Q : Prop.. The problem with this is that P will be assumed as a premise, which it is not
Add Variables P. before the goal declaration. This results in a syntax error.
Am I missing something? I don't seem to be able to figure this out.
The proper solution is 1, and the problem you are expecting is wrong.
When you write:
Variable P: Prop.
You are not assuming that P is inhabited (or, that "P holds"), but only that there exists a proposition named P, a "statement" whose validity is not considered here.
This is very different from writing:
Variable p: P.
Which assumes that there is a proof "p" that the type "P" is inhabited (if P has type Prop, p is a proof of the proposition P), and thus assumes that P is true.
Also, the reason why:
Variables P.
results in a syntax error is that you need to provide a type for each variable introduced (Coq can't figure it out magically when there is no information leading the type inference engine).
So it is perfectly fine to begin your script as:
Section Q5.
Variables P Q : Prop.
Hypothesis premise1 : P \/ Q.
Hypothesis premise2 : ~Q.
Goal P.