Skip to content

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

Merged

Conversation

ttuegel
Copy link
Contributor

@ttuegel ttuegel commented Dec 19, 2018

Remove SymbolOrAliasSorts from MetadataTools.

Removes modules Kore.ASTUtils.SmartConstructors and Kore.ASTUtils.SmartPatterns. New constructors and pattern synonyms for verified patterns reside in Kore.AST.Valid with helpers defined in Kore.AST.Lens.

Reviewer checklist
  • Test coverage: stack test --coverage
  • Public API documentation: stack haddock
  • Style conformance: stylish-haskell

@ttuegel ttuegel force-pushed the remove-symbol-or-alias-sorts branch from 7a49019 to 4be8c8f Compare December 19, 2018 20:34
Copy link
Contributor

@virgil-serbanuta virgil-serbanuta left a 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)
Copy link
Contributor

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

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)
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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.

@virgil-serbanuta
Copy link
Contributor

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.

@eviefp
Copy link

eviefp commented Dec 20, 2018

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.

Copy link
Collaborator

@traiansf traiansf left a 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

@ttuegel ttuegel force-pushed the remove-symbol-or-alias-sorts branch from 4be8c8f to ebbbd09 Compare December 20, 2018 19:37
ttuegel and others added 15 commits December 20, 2018 15:19
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.
@ttuegel ttuegel force-pushed the remove-symbol-or-alias-sorts branch from ebbbd09 to e40ea73 Compare December 20, 2018 22:01
@ttuegel
Copy link
Contributor Author

ttuegel commented Dec 20, 2018

@virgil-serbanuta This is ready for re-review now. I will have performance numbers tomorrow, but I would expect < 5% change from this. SymbolOrAliasSorts was the cheapest lookup in MetadataTools. The biggest gains will come from attribute annotations, but I started with sort annotations because I think that is easier.

Copy link
Contributor

@virgil-serbanuta virgil-serbanuta left a 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.)
@ttuegel ttuegel force-pushed the remove-symbol-or-alias-sorts branch from e40ea73 to 4390f7d Compare December 21, 2018 17:51
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.
@ttuegel ttuegel force-pushed the remove-symbol-or-alias-sorts branch from 4390f7d to 280be68 Compare December 21, 2018 21:00
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.
@ttuegel ttuegel force-pushed the remove-symbol-or-alias-sorts branch from 280be68 to 4700c69 Compare December 21, 2018 21:23
@ttuegel ttuegel merged commit 8210f59 into runtimeverification:master Dec 21, 2018
jberthold pushed a commit that referenced this pull request Apr 10, 2024
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]>
jberthold pushed a commit that referenced this pull request Apr 10, 2024
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]>
jberthold pushed a commit that referenced this pull request Apr 10, 2024
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants