1. 14 Jun, 2018 8 commits
  2. 13 Jun, 2018 3 commits
  3. 09 Jun, 2018 3 commits
  4. 08 Jun, 2018 2 commits
  5. 07 Jun, 2018 2 commits
    • Andrei Paskevich's avatar
      WhyML: allow return types with names: f (a:int) : (x: int, ghost y: int) · 0ffeb3d4
      Andrei Paskevich authored
      These names are only visible under "ensures" but not under "returns".
      If the result is named, the special variable "result" is not used.
      In a tuple, either each component should be named, or none at all.
      Underscores are allowed. Parentheses around the return type are required.
      Each name must be given its own type: "f () : (x y: int)" is rejected.
      Identifiers without cast are treated as types, not as names.
      To name the result without giving its type, use "returns".
    • Raphael Rieu-Helft's avatar
      Add more GMP primitives · 76d42ea4
      Raphael Rieu-Helft authored
  6. 06 Jun, 2018 4 commits
  7. 05 Jun, 2018 5 commits
  8. 04 Jun, 2018 5 commits
  9. 01 Jun, 2018 6 commits
  10. 31 May, 2018 2 commits
    • Jean-Christophe Filliâtre's avatar
      new VC to prove well-foundedness of user-provided variants · 4af9081d
      Jean-Christophe Filliâtre authored
      fixes issue #57
      a new theory relations.WellFounded is introduced for this purpose
      (and must be imported whenever one wants to make use of a custom
      relation for a variant)
      it defines, inductively, a notion of accessibility for a given
      predicate R (x is accessible whenever all elements smaller than x for R
      are alreay accessible)
      whenever one has to prove that a variant decreases, a new VC is also
      generated, to show that the old value of the variant is accessible
      for the order relation
      note: accessibility being defined inductively, proving well-foundedness
      is out of reach of SMT solvers; but at least this is sound now
    • Jean-Christophe Filliâtre's avatar