-
Notifications
You must be signed in to change notification settings - Fork 11
LTL and Staged update #510
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
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3a223b4 to
f78d769
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The LTL and Staged aspects of cooked have been left as is for years (and for good reasons), but it is finally time to update them.
The main reason for the changes is the following observation: while we can express applying a modification at every step in a trace (where it must succeed everywhere), or forking at every location where it actually applies, we cannot express something like "apply a modification everywhere where it can be applied, and leave the other steps as is", which is actually very useful. For instance, the new 'labelled' idiom allows to targets transaction with a specific label, but there is no way to have it fail if the label is not present (which would be the expected behavior when used with somewhere), but still target several transactions in a trace with the label.
A new idiom, let's call it 'wheneverPossible' is in fact needed.
However, this idiom cannot be expressed for good reasons, as it requires to ensure that every step that have not been modified actually could not be modified. Otherwise, the modification should have been applied. The missing piece of the puzzle turns out to be the negation, with an appropriate semantics, where (not A) means that applying A at the current time step would fail (i.e. yield the empty set of traces). At the time of the creation of LTL, we did not find a proper way to handle negation (and implication for that matter, which spawns out of it) and also did not have any use case where it would be relevant, and thus we omitted it, arguing that it was not sound in an operational setting as ours, which seemed right at the time.
However, with the semantics of negation given above, it is actually sound. It is even possible to give a meaning to formula previously seen as obscure, such as "Next A implies B". This is the main focus of this PR: implementing such a semantics for negation, and allowing to speak about implication, or "wheneverPossible".
The main changes to make that possible are as follows:
LtlNotis added to theLtlbuiltinsltlSimplmoves all occurrences ofLtlNotto the leaves of the formula treenowLaterListis now a list of requirements, which either specify that a given atom should be applied, or that it should be ensured that it fails.While I was at it, I took the opportunity to improve the whole framework around
LtlandStaged. Here is a non-exhaustive list of the changes:Stagednow has its own module (and should later on be replaced with proper effects)StateT [Ltl mod]and thus no longer has to manually callnowLaterList, or manually update the state. Instead, they only need to provide whether their builtins will be subject to modification, and if so, how they should be.StartLtlandStopLtlconstructor forLtlOpwhich led to clunky use cases where somebody could call the latter without first calling the former, leading to the need of invokingerror. Instead, aWrapLtlconstructor is given, which does both, around a given computation, ensuring symmetry.MonadLtl,InterpBuiltin, ...)Overall, this should make this whole mechanism clearer, more user friendly, and more structured, while increasing the expressiveness, and paving the way to use a proper existing effect library in the future for those capabilities.