Hi Abel, Depending on the properties that you like to check, you might want to try the Apalache model checker [1]. Although the theory and the tool are not that mature as with TLC, Apalache can handle existential quantifiers over Int and Nat, as long as the checker can replace a quantifier with an integer constant. As long as the model checker has to reason about finite sets, even though their elements may be integers, it should work. I have added tool-specific type annotations in your specification and replaced an infinite set of records with a set filter in ClientReceive, so apalache could digest the spec. (Stephan already mentioned the issue with “idle”, which I have replaced with [status |-> “idle”].) The next question is the kind of property you like to check. At the moment, we can check inductive invariants and safety, by unrolling the transition relation. [1] https://github.com/konnov/apalache/tree/unstable Best regards, Igor -- 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/80E80D29-D342-4A81-B6B4-C380288B0F8C%40gmail.com.
Attachment:
Addition2.tla
Description: Binary data
> On 4 Feb 2020, at 13:34, Stephan Merz <stephan.merz@xxxxxxxxx> wrote:
>
> Hello,
>
> TLC cannot enumerate infinite sets. A typical workaround for quantifier bounds involving infinite sets is to override a set such as Int by a small finite set such as -2 .. 2 if appropriate. (See "Additional Spec Options" -> "Definition Override").
>
> For the snippet shown in the message, I suggest that you avoid quantification altogether and write something like
>
> ServerResponse ==
> /\ serverSt.status = "processing"
> /\ serverSt' = [serverSt EXCEPT !.status = "idle"]
> /\ msgs' = msgs \cup {[type |-> "response", to |-> serverSt.from, res |-> (serverSt.a + serverSt.b)]}
> /\ UNCHANGED clientSt
>
> Note that here the value of serverSt stays a record even when the status is "idle" so that the first conjunct makes sense (and evaluates to FALSE) even if the server is idle. You may want to reset the other record fields to default values so that TLC doesn't generate distinct states that differ only in values of irrelevant record fields.
>
> I believe that you can similarly rewrite the actions ServerReceive and ClientReceive. You still need quantification over integers in ClientSend for expressing non-determinism, and here you will have to use a finite set instead for model checking.
>
> Hope this helps,
> Stephan
>
>
>> On 4 Feb 2020, at 13:09, abel.nieto90@xxxxxxxxx wrote:
>>
>> I'm getting started with TLA+ and wrote a spec for a simple server that adds two integers: https://pastebin.com/Yc8qfwa7
>>
>> When I run TLC, I get the following error:
>>
>>
>> The exception was a java.lang.RuntimeException
>>
>> : TLC encountered a non-enumerable quantifier bound
>>
>> Int.
>>
>> line 46, col 34 to line 46, col 36 of module Addition
>>
>> The error occurred when TLC was evaluating the nested
>>
>> expressions at the following positions:
>>
>> 0. Line 46, column 3 to line 50, column 27 in Addition
>>
>> 1. Line 46, column 6 to line 49, column 84 in Addition
>>
>>
>> The errors refers to a "non-enumerable quantifier bound Int", but `Int` is an enumerable set.
>>
>> The relevant snippet of my code reads
>>
>> ServerResponse == \* server responds
>> /\ \E fromV \in CLIENT, aV \in Int, bV \in Int :
>> /\ serverSt = [status |-> "processing", from |-> fromV, a |-> aV, b |-> bV]
>> /\ serverSt' = "idle"
>> /\ msgs' = msgs \cup {[type |-> "response", to |-> fromV, res |-> (aV + bV)]}
>> /\ UNCHANGED <<clientSt>>
>>
>> What am I doing wrong here? And what's the idiomatic way to "deconstruct" records in TLA?
>>
>> Thanks!
>>
>> Abel
>>
>> --
>> 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/2051d601-952a-434a-a93a-ebccb87843b9%40googlegroups.com.
>
>
> --
> 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/2A642E4C-42AA-40F4-B181-EFE289138E9E%40gmail.com.
--
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/80E80D29-D342-4A81-B6B4-C380288B0F8C%40gmail.com.