You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current algorithm for checking the "eventually" modality has unexpected failures for specifications with next actions that do not make progress. If a specification does not explicitly assign the new values for the specification state using the prime operation, the model checker will not insert a stutter-step. The failure to introduce a stutter-step can cause the eventually checker to refute valid specifications.
next::ActionAlphabetVarsBool
next =do
letter <- plain #letter
#letter .=pure (succ letter)
pure (letter <'z')
The model checker is able to find evidence that satisfies the proposition "eventually, the unprimed value of letter will be equal to the character 'z'". This is due to the final stutter-step satisfying plain #letter == 'z', which can be seen in the trace:
However, if next is reformulated such that #letter .= pure (succ letter) is only evaluated conditionally, then the resulting trace no longer contains the stutter-step satisfying plain #letter == 'z'. For example, the following definition of next:
next::ActionAlphabetVarsBool
next =do
letter <- plain #letter
when (letter <'z') do#letter .=pure (succ letter)
pureTrue
Should be equivalent to the former definition. However, wrapping(.=) with a when guard produces the following trace:
The current algorithm for checking the "eventually" modality has unexpected failures for specifications with
next
actions that do not make progress. If a specification does not explicitly assign the new values for the specification state using theprime
operation, the model checker will not insert a stutter-step. The failure to introduce a stutter-step can cause theeventually
checker to refute valid specifications.Minimal Example
Considering the following specification:
If we define the
next
function to be:The model checker is able to find evidence that satisfies the proposition "eventually, the unprimed value of letter will be equal to the character 'z'". This is due to the final stutter-step satisfying
plain #letter == 'z'
, which can be seen in the trace:However, if
next
is reformulated such that#letter .= pure (succ letter)
is only evaluated conditionally, then the resulting trace no longer contains the stutter-step satisfyingplain #letter == 'z'
. For example, the following definition ofnext
:Should be equivalent to the former definition. However, wrapping
(.=)
with awhen
guard produces the following trace:The text was updated successfully, but these errors were encountered: