Hello, I'll give some answers below and let others complete.
--
Semantically, everything is a set but there are many values for which we do not care to know how they are represented as sets, such as numbers or functions. This is also true for records: think of them as primitive.
How about Cardinality(var) = 4? But probably you also want to fix the "type" of the elements of the set. For example, if you have a set of positive integers, you could write /\ var \in SUBSET (Nat \ {0}) /\ Cardinality(var) = 4 [The Cardinality operator is defined in the FiniteSets module, which you must extend or instantiate.]
/\ WriteExtent \in [start : 0 .. MaxLSN, end : 0 .. MaxLSN] /\ WriteExtent.start <= WriteExtent.end
Do you mean that the value of the variable is always a sequence of such records? Write var \in Seq([start : ..., end : ...])
Sometimes you can actually avoid null values. For example, suppose that you model bank accounts. You may have a constant ID for representing all possible account numbers, a record type Account that represents account information, and a variable account \in [ID -> Account] But since some IDs are not associated with accounts, you need a null value. Instead, you could have two variables /\ usedID \in SUBSET ID \* set of IDs with open accounts /\ account \in [usedID -> Account] Which version works better is for you to decide: it may well be clearer to introduce null values. If you decide to do so, there are different established idioms, choose according to preference and readability of the spec. 1. Make the null value a parameter of your specification. CONSTANT null ASSUME null \notin ... \* the "type" to which you add the null value When running TLC, instantiate the parameter `null' by a model value. 2. Define a null value using a CHOOSE _expression_. null == CHOOSE x : x \notin ... \* again, the type to which the null value is added The Toolbox will recognize such definitions, introduce a model value, and override the definition to assign that model value to `null'. 3. In conjunction with records, you can add an extra field to the record to distinguish records containing valid information from "null" records, like so: var \in [valid : BOOLEAN, ....] \* "...." stands for the fields that your record would normally have Then write var.valid to distinguish "valid" records from null records.
Not sure what these variables represent. You may need a variable representing the control state (similar to how the PlusCal translator encodes the current location of the algorithm or processes) but I don't understand why you use two variables.
I'll leave this one to others who know better. Essentially you only need to version control the .tla and .cfg files in the Model_X subdirectories of the .toolbox directories.
Again, no general answer here: your judgement is key. Checking non-properties can help: assert invariants or temporal properties that you expect your system not to satisfy, then compare the counter-example that TLC produces with what you expect. Also, discuss your specification with a colleague: explaining the choices you made may reveal fallacies in reasoning. Happy TLAing! Stephan
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/B065207B-1E7E-47F3-83DC-E74F361FD81D%40gmail.com. |