1. 06 Jun, 2018 2 commits
  2. 15 May, 2018 1 commit
  3. 14 May, 2018 2 commits
  4. 02 May, 2018 2 commits
  5. 24 Apr, 2018 1 commit
  6. 23 Apr, 2018 1 commit
  7. 18 Apr, 2018 1 commit
  8. 11 Apr, 2018 1 commit
  9. 10 Apr, 2018 1 commit
  10. 09 Apr, 2018 5 commits
  11. 29 Mar, 2018 1 commit
  12. 28 Mar, 2018 3 commits
  13. 24 Mar, 2018 2 commits
  14. 31 Jan, 2018 6 commits
  15. 30 Jan, 2018 1 commit
  16. 29 Jan, 2018 1 commit
  17. 28 Jan, 2018 2 commits
  18. 25 Jan, 2018 1 commit
  19. 18 Jan, 2018 1 commit
  20. 15 Jan, 2018 5 commits
    • Strengthen `related_bind` · bf3aca9a
      Dan Frumin authored
      We define a stronger rule `related_bind_up`, in which there is a baked
      in semantic type `R`. The idea here is that we don't actually require
      the expressions that we bind to have the same syntactic type.
      
      ```
        {E;R::Δ;⤉Γ} ⊨ e1 ≤log≤ e2 : τ
      ∗ (∀ vv, ⟦ τ ⟧ (R::Δ) vv -∗ {E;Δ;Γ} ⊨ K[v1] ≤log≤ K'[v2] : τ')
      ____________________________________________________________
        {E;Δ;Γ} ⊨ K[e1] ≤log≤ K'[e2] : τ'
      ```
      
      We can then use `bin_log_related_weaken_2` to prove the original
      binding rule.
      
      The advantages of the new rule is that it allows us to prove the
      following compatibility rule for seq:
      
      ```
      {E;(R::Δ);⤉Γ} ⊨ e1 ≤log≤ e1' : τ1 -∗
      {E;Δ;Γ} ⊨ e2 ≤log≤ e2' : τ2 -∗
      {E;Δ;Γ} ⊨ (e1;; e2) ≤log≤ (e1';; e2') : τ2.
      ```
      
      The idea here is that we can also pick any *semantic* type to related
      e1 and e1'. For instance, if both e1 and e1' are expressions of type
      Nat then it is not necessarily the case that we can relate them at
      that type -- they might reduce to two different numerals -- but
      it *should* be the case that we can relate their effects, if it makes
      sense. E.g.
      
      ((#l <- #1;; #0) ;; e) ≤ ((#l <- #1;; #1) ;; e)
    • Strengthen `bin_log_related_weaken_2` · 751f6d75
      Dan Frumin authored