Skip to content
Snippets Groups Projects
  1. Feb 28, 2018
  2. Feb 21, 2018
  3. Feb 19, 2018
  4. Feb 16, 2018
  5. Feb 15, 2018
  6. Jan 13, 2018
  7. Dec 22, 2017
  8. Dec 14, 2017
  9. Dec 04, 2017
  10. Nov 27, 2017
  11. Nov 14, 2017
  12. Oct 31, 2017
  13. Oct 30, 2017
  14. Oct 27, 2017
  15. Oct 19, 2017
  16. Oct 09, 2017
  17. Sep 25, 2017
  18. Sep 18, 2017
  19. Aug 22, 2017
  20. Jun 12, 2017
  21. Jun 08, 2017
  22. Mar 24, 2017
    • Robbert Krebbers's avatar
      Generic big operators that are no longer tied to CMRAs. · 6fbff46e
      Robbert Krebbers authored
      Instead, I have introduced a type class `Monoid` that is used by the big operators:
      
          Class Monoid {M : ofeT} (o : M → M → M) := {
            monoid_unit : M;
            monoid_ne : NonExpansive2 o;
            monoid_assoc : Assoc (≡) o;
            monoid_comm : Comm (≡) o;
            monoid_left_id : LeftId (≡) monoid_unit o;
            monoid_right_id : RightId (≡) monoid_unit o;
          }.
      
      Note that the operation is an argument because we want to have multiple monoids over
      the same type (for example, on `uPred`s we have monoids for `∗`, `∧`, and `∨`). However,
      we do bundle the unit because:
      
      - If we would not, the unit would appear explicitly in an implicit argument of the
        big operators, which confuses rewrite. By bundling the unit in the `Monoid` class
        it is hidden, and hence rewrite won't even see it.
      - The unit is unique.
      
      We could in principle have big ops over setoids instead of OFEs. However, since we do
      not have a canonical structure for bundled setoids, I did not go that way.
      6fbff46e
  23. Feb 18, 2017
  24. Feb 07, 2017
  25. Feb 06, 2017
  26. Jan 17, 2017
Loading