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

*From*: Abel Nieto <abel.nieto90@xxxxxxxxx>*Date*: Tue, 4 Feb 2020 04:54:18 -0800 (PST)*References*: <2051d601-952a-434a-a93a-ebccb87843b9@googlegroups.com> <2A642E4C-42AA-40F4-B181-EFE289138E9E@gmail.com>

Thanks! A follow-up question: if I _don't_ do what you suggest and keep the server state in a record, then I get

On Tuesday, February 4, 2020 at 1:34:08 PM UTC+1, Stephan Merz wrote:

-- : 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 nested

I'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,StephanOn 4 Feb 2020, at 13:09, abel....@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 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 tla...@googlegroups.com .

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/ec4db371-64d1-49f2-946e-45a0f422add8%40googlegroups.com.

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

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

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

- Prev by Date:
**Re: [tlaplus] Existential quantifier over integers** - 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):