Implement ORAs - #688
Draft
jlohse-mpi-sws wants to merge 2 commits into
Draft
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
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.
This PR rebases iris-lean on ordered resource algebras (MoSeL) following this Zulip discussion
The main goal is being able to support distributional probabilistic logics, which all need a custom order (PSL, Lilac, Bluebell, pcOL, Amaryllis, opOL). To my understanding, the lack of ORAs is the only reason why the iris-lean implementations of Lilac and Bluebell are currently not uPred instances. The Lilac paper even explicitly mentions the lack of support for a custom order as a main obstruction for mechanizing Lilac in Iris. Another use case of ORAs are linear (non-affine) logics.
I'm putting up the draft implementation for discussion. Doing such a change would mean deviating from Iris-Rocq, since this is not yet implemented there.
All CMRA constructions generalize naturally to a custom order, Auth is affine-only.
Updates and all the uPred laws that involve weakening are affine-only: it is a known limitation that this doesn't work for linear logics.
iProp is also affine-only right now: all infrastructure for higher-order ghost state relies on updates, so I don't see a use-case for non-affine iProp right now, and making it affine-only omits a lot of side conditions.
While the original MoSeL ORA definition only allows reflexive orders, I changed this for compatibility: CMRA does not need a reflexive order, only UCMRA does.
Change List:
Currently a draft because I haven't reviewed every line of AI-generated code. I carefully checked that the code implements what it should. In case the iris-lean community agrees that ORAs should end up upstream, I'm happy to invest the additional time to review the code line-by-line before handing it over.