shortcircuit in forAll and And logic when operating on claim functions #122
Comments
A little more than one year ago @backesj changed the ResoluteProver in commits 08654d2 and eef541c such that While I would think it strange for the language to not short circuit in claims and to do the short circuit in functions, I can understand his interest in getting all of the negative (failing) results in a claim. Today the only difference is that the result returned in the case of the Even though evaluation would not be consistent, it is desirable to have both non-short-circuit ( Likewise for Finally, is there likely to be the need for a short-circuited |
from @agacek : |
I'm a little uncomfortable with a preference option. Composing a systems that are from differing authors may result in differing needs for the evaluation. |
The behavior only changes for failed proofs. For successful proofs, the preference option wouldn't matter. It would mainly be a debugging flag while trying to get a proof to work. |
Most of the time you will have one or more proofs that fail and you will spend time to figure out what needs to be changed in the model to satisfy the proofs. Therefore it is useful to know all of the proof that fail so you know how far you are from the goal of satisfying all proofs. Only when all proofs pass you have a complete assurance case. In that case it does not matter whether we have a shortcircuit. I am making the case that you always want the non-shortcircuit version of Forall and And when their operands are claim functions (proofs). |
The problem with a blanket preference option is that in some cases the author of the claim may depend upon short circuit behavior where using the left term as a guard to prevent an exception. Thus, we would want a per-claim means of selecting whether the evaluation is short circuited. I believe the best way to do this is to build it into the language. I propose we revert the behavior for operator Similarly, the behavior for
Comments, please? |
Sounds good to me.
…On Mon, Apr 16, 2018 at 9:45 AM, kfhoech ***@***.***> wrote:
The problem with a blanket preference option is that in some cases the
author of the claim may depend upon short circuit behavior where using the
left term as a guard to prevent an exception. Thus, we would want a
per-claim means of selecting whether the evaluation is short circuited. I
believe the best way to do this is to build it into the language.
I propose we revert the behavior for operator and to non-short-circuit
when evaluating claims. The behavior for operator andthen is short
circuit. For symmetry the operator or would likewise be non-short-circuit
and also introduce the operator orelse for completeness. (Note this is
consistent with the language convention for Ada.) Evaluation would remain
short-circuit for all of these operators when evaluating functions.
Similarly, the behavior for forall would revert to non-short-circuit when
evaluating claims. It is debatable whether to introduce a short-circuit
version of forall (perhaps called forallupto or forallshort).
Use of exists in claims currently is disallowed. I propose this remains
unchanged.
Comments, please?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#122 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAKgiN_0i6C_wRk_9L5qpJ0BltOtNBkQks5tpK6QgaJpZM4TTpR->
.
|
How about disallowing implies? My problem is that it evaluates to true when the left operand is false. Often when I used it I assumed it meant "andthen". As to a shortcut version for Forall: I am ok with not introducing it. |
I concur with the argument that If there are models out there with Consider the as proposal modified to remove the short-circuit versions of |
Resolved by Pull Request 126. |
At the time I wrote the Resolute documentation shortcircuit on forAll and And was disabled when used with operands that are claim functions.
A little while ago someone reintroduced the shortcircuit on forAll and And, i.e., they stop evaluating claim function calls when the first one returning false/fail is encountered. As a result, when I verify claims on a collection of buses it does not evaluate all of them unless they all return true. This behavior is like a compiler stopping after the first syntax error and not telling about the rest of them.
Shortcircuit is ok when these operators are used to call on computational functions.
The text was updated successfully, but these errors were encountered: