-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Meaning of ? variables #3531
Comments
I think that having an existential in the config and predicate is also indicative of an error in this case (or, at least, a confusion). I think it would be useful to have more clarity about what use-cases we are trying to support, and what ways of encoding them are acceptable to end-users (also see the examples below). Next, we should decide in which case we actually need to quantify the variables we use (see the end of the paragraph, we don't always need to quantify existential variables). Let's take a few examples:
I'm claiming that:
A few comments about the encodings above:
Depending on what we want to do, we may or may not be able to use the same representation for all examples above. As an example, in all-path proofs, existential variables are transformed in universally quantified variables (e.g. if we want to prove |
also related related: #1046 |
@goodlyrottenapple this was opened a while ago. What were the actions needed to be taken here? |
Honestly, I'm not sure...probably best to revisit this if/when pertinent to the booster. We don't really have the capacity to try to fix this in the old backend and we seem to have work-arounds in place. |
…3253) * haskell-backend/src/main/native/haskell-backend: 5dc023d92 - Update dependency: deps/k_release (#3531) * Sync flake inputs to submodules * haskell-backend/src/main/native/haskell-backend: 858a31999 - Adjust json schema to use LeftAssoc and RightAssoc (#3548) * Sync flake inputs to submodules --------- Co-authored-by: rv-jenkins <[email protected]>
We seem to currently have an inconsistent state of existential variables.
The issue originally arose from this bug: runtimeverification/haskell-backend#3605, where the backend claims
#Exists X . #Exists Y . { true #Equals 0 >Int Y } #And { true #Equals 0 <=Int X }
is invalid.Upon investigation, it turned out the backend was stripping the existentials (this change was introduced by runtimeverification/haskell-backend#3193) and essentially checking
#Forall X . #Forall Y . { true #Equals 0 >Int Y } #And { true #Equals 0 <=Int X }
with Z3, which is of course invalid.However, when we try to revert the above change to get the correct behaviour for the aforementioned bug, we run into the following error:
https://github.com/runtimeverification/haskell-backend/blob/2e33122cd354045da4e5f40dea9344e02c673a64/kore/src/Kore/Simplify/Exists.hs#L397-L401
This error arises when we get an existential variable appearing both in the configuration and the requires/ensures clause, e.g. when applying this foundry rule:
https://github.com/runtimeverification/evm-semantics/blob/c84e3466aa2ca2f4dea43870369b2ccab012e2f4/include/kframework/foundry.md?plain=1#L565-L570
since the above rule is encoded in kore as:
or whenever pyk sends over an implies request and explicitly applies an existential quantifier over any unbound variables on the RHS (from runtimeverification/haskell-backend#3620 (comment)):
Since the introduction of runtimeverification/haskell-backend#3193, we have essentially been turning all these existential variables into universal ones, hence the above error never occurred, but this is obviously not sound as evidenced by runtimeverification/haskell-backend#3605. The question is, which of the following options is the correct one?
?
vars on the RHS of a rewrite rule to a universally quantified one (this is seemingly the status quo, given [Simplification request] Top-level existential elimination haskell-backend#3193The text was updated successfully, but these errors were encountered: