-
Notifications
You must be signed in to change notification settings - Fork 42
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
Types specifying the simplify-implication
RPC endpoint
#3614
base: master
Are you sure you want to change the base?
Changes from all commits
83ea3fa
1a91aea
e8114e9
32ec748
e919814
1019618
32dbb64
839fe34
60990ab
8785dc9
5b82de9
501ad4c
27c81b4
3f22ee1
28bbb0a
0428527
6beee9b
6a712b2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -388,6 +388,127 @@ Same as for execute | |||||
} | ||||||
``` | ||||||
|
||||||
## Simplify Implication | ||||||
|
||||||
### Request: | ||||||
|
||||||
```json | ||||||
{ | ||||||
"jsonrpc": "2.0", | ||||||
"id": 1, | ||||||
"method": "simplify-implication", | ||||||
"params": { | ||||||
"antecedent": {"format": "KORE", "version": 1, "term": {}}, | ||||||
"consequent": {"format": "KORE", "version": 1, "term": {}}, | ||||||
"module": "MODULE-NAME" | ||||||
} | ||||||
} | ||||||
``` | ||||||
|
||||||
Optional parameters: `module` (main module name) | ||||||
|
||||||
The request format is shared with the `"implies"` method. | ||||||
|
||||||
**NOTE**: `"simplify-implication"` currently only has a stub implementation in `kore-rpc`. The real implementation is in `kore-rpc-booster` (see [hs-backend-booster](https://github.com/runtimeverification/hs-backend-booster) repository). The documentation will reside here for consistency. | ||||||
|
||||||
### Error Response: | ||||||
|
||||||
Errors in decoding the `antecedent` or `consequent` terms are reported similar as for execute. | ||||||
|
||||||
### Correct Response: | ||||||
|
||||||
The endpoint is a lightweight variant fo the `"implies"` endpoint, which checks implication using matching between configuration terms and a lightweight (using K simplifications, rather than encoding to SMT) constraint subsumption. | ||||||
|
||||||
The implication can be "valid", "invalid" and "unknown". The result is returned in the `"validity"` field. The following results are possible: | ||||||
|
||||||
#### Implication is **valid** | ||||||
|
||||||
A constrained substitution as the result, and this is only returned if the implication is valid. | ||||||
|
||||||
``` | ||||||
{ | ||||||
"jsonrpc": "2.0", | ||||||
"id": 1, | ||||||
"result": { | ||||||
"validity": {"tag": "implication-valid"}, | ||||||
"substitution": {"format": "KORE", "version": 1, "term": {}}, | ||||||
} | ||||||
} | ||||||
``` | ||||||
|
||||||
#### Implication **invalid**: terms do not match | ||||||
|
||||||
Matching between antecedent and consequent configurations failed (different constructors, shared variables, sort error, etc.), constraints has not been subsumption been attempted. No matching substitution is returned. | ||||||
|
||||||
``` | ||||||
{ | ||||||
"jsonrpc": "2.0", | ||||||
"id": 1, | ||||||
"result": { | ||||||
"validity": {"tag": "implication-valid", | ||||||
"contents": {"tag": "matching-failed", | ||||||
"contents": "Shared variables: X:SortWordStack{}" | ||||||
}}, | ||||||
} | ||||||
} | ||||||
``` | ||||||
|
||||||
#### Implication **invalid**: terms match, but constraints subsumption failed | ||||||
|
||||||
Matching between antecedent and consequent configurations is successful, but constraints do not agree. Response contains the matching substitution and the unsatisfiable core of constraints. | ||||||
|
||||||
``` | ||||||
{ | ||||||
"jsonrpc": "2.0", | ||||||
"id": 1, | ||||||
"result": { | ||||||
"validity": {"tag": "implication-valid", | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
I think this should likely actually just be |
||||||
"contents": {"tag": "constraint-subsumption-failed", | ||||||
"contents": {"format": "KORE", "version": 1, "term": {}} | ||||||
}}, | ||||||
"substitution": {"format": "KORE", "version": 1, "term": {}}, | ||||||
} | ||||||
} | ||||||
``` | ||||||
|
||||||
#### Implication **unknown**: matching indeterminate | ||||||
|
||||||
The matching algorithm is incomplete and may return an indeterminate result. The response will contains the subterms that the algorithm could not know how to match. No substitution is returned. | ||||||
|
||||||
``` | ||||||
{ | ||||||
"jsonrpc": "2.0", | ||||||
"id": 1, | ||||||
"result": { | ||||||
"validity": {"tag": "implication-unknown", | ||||||
"contents": {"tag": "matching-unknown", | ||||||
"contents": {"first" : {"format": "KORE", "version": 1, "term": {}} | ||||||
,"second" : {"format": "KORE", "version": 1, "term": {}} | ||||||
} | ||||||
}}, | ||||||
} | ||||||
} | ||||||
``` | ||||||
|
||||||
#### Implication **unknown**: constraint subsumption indeterminate | ||||||
|
||||||
If matching is successful, but the constraint solver procedure (internal, or the SMT solver if enabled) returned "unknown". Response contains the matching substitution and the unknown core of constraints. | ||||||
|
||||||
``` | ||||||
{ | ||||||
"jsonrpc": "2.0", | ||||||
"id": 1, | ||||||
"result": { | ||||||
"validity": {"tag": "implication-unknown", | ||||||
"contents": {"tag": "constraint-subsumption-unknown", | ||||||
"contents": {"tag": "constraint-subsumption-failed", | ||||||
"contents": {"format": "KORE", "version": 1, "term": {}} | ||||||
}}, | ||||||
"substitution": {"format": "KORE", "version": 1, "term": {}}, | ||||||
} | ||||||
} | ||||||
``` | ||||||
Comment on lines
+493
to
+510
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How is this different than "Implication invalid: terms match, but constraints subsumption failed" There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought, we'd want to have a tri-state constraint subsumption check, just like we have a tri-stat matching routine. But perhaps we can indeed expose the "failed" and "unknown" constraint subsumption as just "failed" and have less user-facing cases. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Part of the confusion for me is that for the failure cases, you're using "terms don't
The key here is that unification and matching are different algorithms, different complexities, and different properties. Saying a term matches another means it's completely subsumed, and saying that they don't unify means they have no overlap. So I guess the language here needs to be cleared up, because here for example Unification and matching are not interchangeable. See https://github.com/runtimeverification/hs-backend-booster/issues/193 again for the desired interface. |
||||||
|
||||||
## Add-module | ||||||
|
||||||
### Request | ||||||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
`X => X`, response `ImplicationUnknown`, with empty substitution. `simplify-implication` is only implemented as a stub in `kore-rpc`. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
{ | ||
"format": "KORE", | ||
"version": 1, | ||
"term": { | ||
"tag": "EVar", | ||
"name": "X", | ||
"sort": { | ||
"tag": "SortVar", | ||
"name": "S" | ||
} | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
{ | ||
"format": "KORE", | ||
"version": 1, | ||
"term": { | ||
"tag": "EVar", | ||
"name": "X", | ||
"sort": { | ||
"tag": "SortVar", | ||
"name": "S" | ||
} | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
../../resources/empty/definition.kore |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
{"jsonrpc":"2.0","id":1,"result":{"validity":{"tag":"implication-unknown","contents":{"tag":"matching-unknown","contents":[{"format":"KORE","version":1,"term":{"tag":"EVar","name":"X","sort":{"tag":"SortVar","name":"S"}}},{"format":"KORE","version":1,"term":{"tag":"EVar","name":"X","sort":{"tag":"SortVar","name":"S"}}}]}}}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The result here should be "unification-failed", and that's what we should be checking. Eventually, if unification succeeds and matching fails, we want ot return an core problem which may or may not be unsat, that the user can then forward to the more powerful implies endpoint.
Just want to make sure that when we get this response back, what it actually means is there is absolutely no overlap between the terms, we know because we found differing constructors.