Add lemmas for commuting funcs with folds
These lemmas were helpful to me in recent proofs (in particular, the multiset one is used for iris/iris#923.) They allow for moving a unitary function on a fold accumulator in and out of the fold as necessary, provided the function commutes appropriately with the fold function.
The location of the multiset lemma in the file is not ideal, since it has to come after Fixed by Robbert's changes.gmultiset_ind
, which is well after all the other fold lemmas. However, proving it without gmultiset_ind
is much harder, and moving gmultiset_ind
further up the file is itself non-trivial, so I've opted not to try.
Merge request reports
Activity
mentioned in merge request iris!923 (merged)
- Resolved by Isaac van Bakel
- Resolved by Isaac van Bakel
Thanks for the MR. Some comments:
- It would be good to also have this lemma for sets and lists, and make sure the names are consistent
- The lemma for multisets seems weaker, it requires commutativity and associativity for all elements, and not just those in the set. I think it makes sense to have both versions (with
Comm
/Assoc
and more general premise) for all fold functions.
The lemma for multisets seems weaker, it requires commutativity and associativity for all elements, and not just those in the set. I think it makes sense to have both versions (with
Comm
/Assoc
and more general premise) for all fold functions.This is in part just for consistency with the rest of the set API, which also requires
Comm
andAssoc
when just an element-wise restriction would do.I'm happy to try and add these, but is there a nice restatement for maps? I could make a version dropping the key inequality and lookup requirements from the commutativity condition, but maybe there's a better way to generalise it?
Edited by Isaac van Bakel- Resolved by Isaac van Bakel
- Resolved by Isaac van Bakel
added 2 commits
added 2 commits
All of these lemmas now have stronger variants which at least only require the commutativity properties to hold on elements of the structure, rather than all values in the type.
The lemmas are not exactly identical. Some of this is due to existing style, but the biggest issue is: the
gmultiset
strong variant only holds for equality. The other strong lemmas are stated for any preorder. This is due to some weaknesses in thegmultiset
API, which having tried to solve, would be a bit of work - namely, there needs to be a proof thatset_fold
forgmultiset
is at leastProper (eq ==> equiv ==> eq)
(and ideallyProper (R ==> equiv ==> R)
for the right R), similar to theset_fold_proper
lemma for finite sets. It would also help to be able to define fold induction, but I don't think this is strictly necessary.- Resolved by Robbert Krebbers
@robbertkrebbers Is there anything left to do for this MR?
mentioned in merge request !492 (merged)
mentioned in merge request !493 (merged)
added 31 commits
-
02e829ad...b4e387e6 - 24 commits from branch
iris:master
- 1f6c9330 - Use `Proper (.. => impl)` instead of `Proper (.. => iff)` and `∀ x, Proper ..`...
- 3e68fc48 - Add lemmas for commuting funcs with folds
- aff46f6d - Extend fold-commuting lemmas to lists, sets
- f4c6218d - Strengthen multiset disj union lemma
- 445e0eb5 - Strengthen all fold commutativity lemmas
- 9d280a1d - Rename comm_acc -> comm_accum
- 890eab4f - Weaken premises and tweak proofs.
Toggle commit list-
02e829ad...b4e387e6 - 24 commits from branch