Skip to content
Snippets Groups Projects
  1. Jun 24, 2019
  2. Jun 11, 2019
  3. May 24, 2019
    • Robbert Krebbers's avatar
      More consistent naming for `auth`. · 597ec42e
      Robbert Krebbers authored
      This MR is a follow up on the renamings performed (implicitly) as part of
      !215. This MR makes the following changes:
      
      - `auth_both_frac_valid` and `auth_both_valid` are now of the same shape
        as `auth_both_frac_validN` and `auth_both_validN`. That is, both are
        now biimplications.
      - The left-to-right  direction of `auth_both_frac_valid` and
        `auth_both_valid` only holds in case the camera is discrete. The
        right-to-left versions for non-discrete cameras are prefixed `_2`, the
        convention that we use throughout the development.
      - Change the direction of lemmas like `auth_frag_valid` and
        `auth_auth_valid` so that it's consistent with the other lemmas. I.e.
        make sure that the ◯ and ● are always on the LHS of the biimplication.
      597ec42e
  4. May 23, 2019
  5. Oct 29, 2018
    • Jacques-Henri Jourdan's avatar
      wp_pures. · 2950fca6
      Jacques-Henri Jourdan authored
      2950fca6
    • Jacques-Henri Jourdan's avatar
      A specific constructor for injecting values in expressions · 9646293e
      Jacques-Henri Jourdan authored
      We add a specific constructor to the type of expressions for injecting
      values in expressions.
      
      The advantage are :
      - Values can be assumed to be always closed when performing
        substitutions (even though they could contain free variables, but it
        turns out it does not cause any problem in the proofs in
        practice). This means that we no longer need the `Closed` typeclass
        and everything that comes with it (all the reflection-based machinery
        contained in tactics.v is no longer necessary). I have not measured
        anything, but I guess this would have a significant performance
        impact.
      
      - There is only one constructor for values. As a result, the AsVal and
        IntoVal typeclasses are no longer necessary: an expression which is
        a value will always unify with `Val _`, and therefore lemmas can be
        stated using this constructor.
      
      Of course, this means that there are two ways of writing such a thing
      as "The pair of integers 1 and 2": Either by using the value
      constructor applied to the pair represented as a value, or by using
      the expression pair constructor. So we add reduction rules that
      transform reduced pair, injection and closure expressions into values.
      At first, this seems weird, because of the redundancy. But in fact,
      this has some meaning, since the machine migth actually be doing
      something to e.g., allocate the pair or the closure.
      
      These additional steps of computation show up in the proofs, and some
      additional wp_* tactics need to be called.
      9646293e
  6. Jun 20, 2018
  7. May 17, 2018
  8. May 02, 2018
  9. Apr 25, 2018
  10. Dec 23, 2017
  11. Oct 25, 2017
  12. Oct 10, 2017
  13. Sep 26, 2017
    • Robbert Krebbers's avatar
      Fix issue #98. · e17ac4ad
      Robbert Krebbers authored
      We used to normalize the goal, and then checked whether it was of
      a certain shape. Since `uPred_valid P` normalized to `True ⊢ P`,
      there was no way of making a distinction between the two, hence
      `True ⊢ P` was treated as `uPred_valid P`.
      
      In this commit, I use type classes to check whether the goal is of
      a certain shape. Since we declared `uPred_valid` as `Typeclasses
      Opaque`, we can now make a distinction between `True ⊢ P` and
      `uPred_valid P`.
      e17ac4ad
  14. Jun 08, 2017
  15. Jan 11, 2017
  16. Jan 09, 2017
  17. Jan 06, 2017
  18. Jan 05, 2017
  19. Jan 03, 2017
  20. Dec 09, 2016
  21. Dec 08, 2016
  22. Dec 06, 2016
  23. Nov 22, 2016
  24. Nov 17, 2016
  25. Nov 03, 2016
  26. Nov 01, 2016
  27. Oct 27, 2016
  28. Oct 25, 2016
    • Robbert Krebbers's avatar
      Generalize update tactics into iMod and iModIntro for modalities. · fc30ca08
      Robbert Krebbers authored
      There are now two proof mode tactics for dealing with modalities:
      
      - `iModIntro` : introduction of a modality
      - `iMod pm_trm as (x1 ... xn) "ipat"` : eliminate a modality
      
      The behavior of these tactics can be controlled by instances of the `IntroModal`
      and `ElimModal` type class. We have declared instances for later, except 0,
      basic updates and fancy updates. The tactic `iMod` is flexible enough that it
      can also eliminate an updates around a weakest pre, and so forth.
      
      The corresponding introduction patterns of these tactics are `!>` and `>`.
      
      These tactics replace the tactics `iUpdIntro`, `iUpd` and `iTimeless`.
      
      Source of backwards incompatability: the introduction pattern `!>` is used for
      introduction of arbitrary modalities. It used to introduce laters by stripping
      of a later of each hypotheses.
      fc30ca08
    • Robbert Krebbers's avatar
      Rename rvs -> bupd (basic update), pvs -> fupd (fancy update). · 1b85d654
      Robbert Krebbers authored
      And also rename the corresponding proof mode tactics.
      1b85d654
  29. Oct 06, 2016
Loading