Skip to content
  • Robbert Krebbers's avatar
    Make big_opL type class opaque. · 02a0929d
    Robbert Krebbers authored
    This commit fixes the issues that refolding of big operators did not work nicely
    in the proof mode, e.g., given:
        Goal forall M (P : nat → uPred M) l,
          ([∗ list] x ∈ 10 :: l, P x) -∗ True.
        Proof. iIntros (M P l) "[H1 H2]".
    We got:
        "H1" : P 10
        "H2" : (fix
                big_opL (M0 : ofeT) (o : M0 → M0 → M0) (H : Monoid o) (A : Type)
                        (f : nat → A → M0) (xs : list A) {struct xs} : M0 :=
                  match xs with
                  | [] => monoid_unit
                  | x :: xs0 => o (f 0 x) (big_opL M0 o H A (λ n : nat, f (S n)) xs0)
                  end) (uPredC M) uPred_sep uPred.uPred_sep_monoid nat
                 (λ _ x : nat, P x) l
    The problem here is that proof mode looked for an instance of `IntoAnd` for
    `[∗ list] x ∈ 10 :: l, P x` and then applies the instance for separating conjunction
    without folding back the fixpoint. This problem is not specific to the Iris proof
    mode, but more of a general problem of Coq's `apply`, for example:
        Goal forall x l, Forall (fun _ => True) (map S (x :: l)).
          intros x l. constructor.
         Forall (λ _ : nat, True)
           ((fix map (l0 : list nat) : list nat :=
              match l0 with
              | [] => []
              | a :: t => S a :: map t
              end) l)
    This commit fixes this issue by making the big operators type class opaque and instead
    handle them solely via corresponding type classes instances for the proof mode tactics.
    Furthermore, note that we already had instances for persistence and timelessness. Those
    were really needed; computation did not help to establish persistence when the list in
    question was not a ground term. In fact, the sitation was worse, to establish persistence
    of `[∗ list] x ∈ 10 :: l, P x` it could either use the persistence instance of big ops
    directly, or use the persistency instance for `∗` first. Worst case, this can lead to an
    exponential blow up because of back tracking.