-
Notifications
You must be signed in to change notification settings - Fork 45
Remove SymbolOrAliasSorts #392
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
Remove SymbolOrAliasSorts #392
Conversation
7a49019
to
4be8c8f
Compare
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.
Thanks for doing this, each time I wrote give sortTools
I thought how nice it could be with annotations!
You said that there was some fragile code that dealt with sorts. If there aren't many instances, could you add todos for all of them, explaining the issue (with my name, unless you want to fix them)? If there are many instances, could you add a few TODOS for places that are good examples for these issues, mentioning that all similar instances must be fixed?
@traiansf I didn't have time to look at things under kore/test, you should keep that in mind when reviewing.
@@ -459,13 +459,13 @@ BNF definitions: | |||
@ | |||
⟨variable⟩ ::= ⟨object-variable⟩ | ⟨meta-variable⟩ | |||
@ | |||
unifiedVariableParser :: Parser (UnifiedVariable Variable) | |||
-} | |||
unifiedVariableParser :: Parser (Unified Variable) |
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.
This is not used anywhere, right? @traiansf Do you remember why we have this? Is it worth keeping?
If nobody can come up with a reason for keeping it, I think we should delete this function.
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.
I think that we originally though we might need it, and it somehow seemed to fit into the overall parsing picture; if it's not used, we should drop it; it's not hard to write it again if we decide it's useful later.
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.
It's used in the Unparse
tests to check that we can correctly do the parsing-unparsing round-trip.
, Ord (variable level) | ||
, Show (variable level) |
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.
Could we group these two constraints into a single one, DebugVariable or something similar (not necessarily in this PR)? I guess that's their purpose, so we should be explicit about what happens.
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.
Yes, I will make a separate pull request for that. I think it should be a class for any syntactic object, not just variables; the Unparse (variable level)
is just getting pulled in to satisfy an Unparse (Pattern level domain variable child)
instance somewhere. But at this location, the constraint could just be DebugSyntax (variable level)
.
in | ||
(result, SimplificationProof) | ||
where | ||
Application { applicationSymbolOrAlias = patternHead } = app |
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.
I'm starting to like this way of extracting field values.
Oh, one more thing: if I remember correctly, you said that you expected some performance improvement. It would be nice if that information would be present in the PR description and if it would preserved in the commit history after merging. |
It would be even nicer if we could somehow use Jenkins to time at least the integration suite and export the data somewhere, to generate a report. Now that I think about it, would be interesting to also track coverage and docs. |
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.
Tests look OK to me. I'll leave the final approve to @virgil-serbanuta
4be8c8f
to
ebbbd09
Compare
The sort `predicateSort` is renamed to `_PREDICATE{}`; the underscore makes it an invalid identifier in the concrete syntax of Kore. The definition verifier now ensures that it is not defined, just to be pedantic.
Types `Module` and `Definition` are now parameterized by sentence type and gain instances `Functor`, `Foldable`, and `Traversable`.
Add `eraseSentenceAnnotations` to erase annotations from pure `Sentence`s and `eraseUnifiedSentenceAnnotations` to erase annatations from `UnifiedSentence`s.
The function `renderDefault` is a helper for writing error messages. The functions `parameters`, `arguments`, and `attributes` are useful for writing instances of `Unparse`.
Unlike `Kore.ASTHelpers.substituteSortVariables`, this function does not fail if a sort variable is not found.
The new module Kore.AST.Valid implements constructors and patterns for valid pure Kore syntax trees.
`extract` is a well-known name used by the `Comonad` class. As we use `Comonad` more, this name will collide.
`Control.Comonad` is part of the intended interface of the `PurePattern` type.
The `HasCallStack` constraint causes the error message to appear where `testSymbolWithSolver` is called.
ebbbd09
to
e40ea73
Compare
@virgil-serbanuta This is ready for re-review now. I will have performance numbers tomorrow, but I would expect < 5% change from this. |
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.
I've added a new comment in this review round, and you still have two from the previous round: the parser one and the performance stats one. I'm not going to insist on the last one if you think it does not make sense.
Type SymbolOrAliasSorts and the MetadataTools field symbolOrAliasSorts are not necessary with pattern sort annotations. Concrete execution time decreases by 6% for IMP programs, but languages with larger definitions may see greater improvement because the complexity of sort lookup is reduced from logarithmic (in the number of defined symbols) to constant-time.
`translatePredicate` attempts the following, in order, to translate the children of an `\equals` predicate: 1. Translate children as builtin domain value patterns. 2. Translate children as predicates. 3. Translate the entire predicate uninterpreted. We always attempt translation as builtin domain value patterns first because that is most specific. We cannot use the sorts alone to choose between translating as builtin domain value patterns or predicates, because predicates can occur in any sort.
Specifying all class functions for these instances for `PurePattern` and `KorePattern` allows us to take advantage of specialized implementations in the parent instances. (I originally wrote this patch when I was on a performance wild-goose chase. In the end, this is worth less than 0.5% on performance, but I wasn't going to throw it away.)
e40ea73
to
4390f7d
Compare
Functions bottomOf and topOf create a \bottom or \top expanded pattern of a given sort.
Function mkSortVariable constructs a sort variable with the given name, the analog of function mkSort, which constructs an actual sort.
4390f7d
to
280be68
Compare
The search command now uses forceSort to coerce its result into the sort of the original configuration pattern. The prove command uses mkSortVariable to construct a dummy sort variable if the sort of the result is flexible.
280be68
to
4700c69
Compare
Fixes runtimeverification/hs-backend-booster#373 This PR makes `kore-rpc-booster` return `"execute"` responses with `"reason": "aborted"` in cases when Kore's simplifier fails due to `DecidePredicateUnknown` in the post-exec simplification in `Proxy.hs`. **Scenario before** ``` "execute" request -> booster execute (X steps) > kore execute (0-1steps) -> kore simplify -> DecidePredicateUnknown -> JsonRpcError` ``` returning `JsonRpcError` resulted in loosing information gained by executing in booster for X steps + in kore for up to 1 step. **Scenario now** ``` "execute" request -> booster execute (X steps) > kore execute (0-1steps) -> kore simplify -> DecidePredicateUnknown -> ExecuteResult {reason=Aborted, unknownPredicate = <predicate>}` ``` this this change, we return the reached state (may be branching) and do not lose information anymore. Additionaly, we return the unknown predicate, so that `pyk` can decide what to do with these. PR to `pyk` that takes advantage of this feature by intrroducing `Undecided` nodes to KCFG: runtimeverification/pyk#744 --------- Co-authored-by: Samuel Balco <[email protected]> Co-authored-by: github-actions <[email protected]> Co-authored-by: rv-jenkins <[email protected]>
Fixes runtimeverification/hs-backend-booster#373 This PR makes `kore-rpc-booster` return `"execute"` responses with `"reason": "aborted"` in cases when Kore's simplifier fails due to `DecidePredicateUnknown` in the post-exec simplification in `Proxy.hs`. **Scenario before** ``` "execute" request -> booster execute (X steps) > kore execute (0-1steps) -> kore simplify -> DecidePredicateUnknown -> JsonRpcError` ``` returning `JsonRpcError` resulted in loosing information gained by executing in booster for X steps + in kore for up to 1 step. **Scenario now** ``` "execute" request -> booster execute (X steps) > kore execute (0-1steps) -> kore simplify -> DecidePredicateUnknown -> ExecuteResult {reason=Aborted, unknownPredicate = <predicate>}` ``` this this change, we return the reached state (may be branching) and do not lose information anymore. Additionaly, we return the unknown predicate, so that `pyk` can decide what to do with these. PR to `pyk` that takes advantage of this feature by intrroducing `Undecided` nodes to KCFG: runtimeverification/pyk#744 --------- Co-authored-by: Samuel Balco <[email protected]> Co-authored-by: github-actions <[email protected]> Co-authored-by: rv-jenkins <[email protected]>
Fixes runtimeverification/hs-backend-booster#373 This PR makes `kore-rpc-booster` return `"execute"` responses with `"reason": "aborted"` in cases when Kore's simplifier fails due to `DecidePredicateUnknown` in the post-exec simplification in `Proxy.hs`. **Scenario before** ``` "execute" request -> booster execute (X steps) > kore execute (0-1steps) -> kore simplify -> DecidePredicateUnknown -> JsonRpcError` ``` returning `JsonRpcError` resulted in loosing information gained by executing in booster for X steps + in kore for up to 1 step. **Scenario now** ``` "execute" request -> booster execute (X steps) > kore execute (0-1steps) -> kore simplify -> DecidePredicateUnknown -> ExecuteResult {reason=Aborted, unknownPredicate = <predicate>}` ``` this this change, we return the reached state (may be branching) and do not lose information anymore. Additionaly, we return the unknown predicate, so that `pyk` can decide what to do with these. PR to `pyk` that takes advantage of this feature by intrroducing `Undecided` nodes to KCFG: runtimeverification/pyk#744 --------- Co-authored-by: Samuel Balco <[email protected]> Co-authored-by: github-actions <[email protected]> Co-authored-by: rv-jenkins <[email protected]>
Remove
SymbolOrAliasSorts
fromMetadataTools
.Removes modules
Kore.ASTUtils.SmartConstructors
andKore.ASTUtils.SmartPatterns
. New constructors and pattern synonyms for verified patterns reside inKore.AST.Valid
with helpers defined inKore.AST.Lens
.Reviewer checklist
stack test --coverage
stack haddock
stylish-haskell