[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*From*: Leslie Lamport <tlaplus.ll@xxxxxxxxx>*Date*: Tue, 4 Feb 2020 19:05:18 -0800 (PST)*References*: <2051d601-952a-434a-a93a-ebccb87843b9@googlegroups.com> <2A642E4C-42AA-40F4-B181-EFE289138E9E@gmail.com> <ec4db371-64d1-49f2-946e-45a0f422add8@googlegroups.com> <F7A9F48E-881E-4F5C-B987-9BDBF5973483@gmail.com>

A minor correction to Stephan's post. TLC does not automatically override any definition.

What Stephan meant is that TLC can be directed to override the definition and consider `idle'

to be a model value. When you create a new model in the Toolbox, it will automatically

add the override directive to what the model tells TLC to do.

-- What Stephan meant is that TLC can be directed to override the definition and consider `idle'

to be a model value. When you create a new model in the Toolbox, it will automatically

add the override directive to what the model tells TLC to do.

Leslie

On Tuesday, February 4, 2020 at 7:00:29 AM UTC-8, Stephan Merz wrote:

On Tuesday, February 4, 2020 at 7:00:29 AM UTC-8, Stephan Merz wrote:

In TLA+, we do not know if 42 = {} or if "idle" = [status |-> "processing", from |-> "clientA", a |-> -23, b |-> 4711], that's why TLC complains about being unable to compare such values.If you want to use an atomic value for the state where the server is idle, you can do something likeidle == CHOOSE x : x \notin ServerState(where ServerState is the set of records representing states where the status is "processing"). By the axioms of set theory, we know that some such value exists and by definition it is different from any of the ServerState records. TLC should automatically override this definition by a model value and will know that the comparison yields FALSE. If it doesn't do this automatically, use a manual definition override to achieve this.StephanOn 4 Feb 2020, at 13:54, Abel Nieto wrote:Thanks! A follow-up question: if I _don't_ do what you suggest and keep the server state in a record, then I get: Attempted to check equality of string "idle" with non-string:

[status |-> "processing", from |-> "a", a |-> -5..5, b |-> -5..5]

The error occurred when TLC was evaluating the nestedI'll end up doing what you suggested, but I'm curious if there's a way to compare values of different types.

On Tuesday, February 4, 2020 at 1:34:08 PM UTC+1, Stephan Merz 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 likeServerResponse ==/\ serverSt.status = "processing"/\ serverSt' = [serverSt EXCEPT !.status = "idle"]/\ msgs' = msgs \cup {[type |-> "response", to |-> serverSt.from, res |-> (serverSt.a + serverSt.b)]}/\ UNCHANGED clientStNote 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,StephanI'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 readsServerResponse == \* 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

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

To view this discussion on the web visit https://groups.google.com/d/msgid/tlaplus/ec4db371- .64d1-49f2-946e-45a0f422add8% 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/1e637c21-841d-482c-9603-46e789721f63%40googlegroups.com.

**References**:**[tlaplus] Existential quantifier over integers***From:*abel . nieto90

**Re: [tlaplus] Existential quantifier over integers***From:*Stephan Merz

**Re: [tlaplus] Existential quantifier over integers***From:*Abel Nieto

**Re: [tlaplus] Existential quantifier over integers***From:*Stephan Merz

- Prev by Date:
**Re: [tlaplus] Time-outs** - Next by Date:
**Re: [tlaplus] Existential quantifier over integers** - Previous by thread:
**Re: [tlaplus] Existential quantifier over integers** - Next by thread:
**Re: [tlaplus] Existential quantifier over integers** - Index(es):