1. 22 Jun, 2017 1 commit
    • Andrei Paskevich's avatar
      WhyML: check type invariants · 15fc3d65
      Andrei Paskevich authored
      Type declarations for records (incuding the private records) can
      now be followed by a "witness": a set of values for the record
      fields that must satisfy the type invariant (if any). The fields
      must be initialized with pure terminating program expressions.
      The current syntax, proposed by Martin, is
      
          type t 'a = { f: ty1; g: ty2 }
            invariant { J[f,g] }
            by { f = e1; g = e2 }
      
      The generated proof obligation is the VC for
      
          let g = e2 in let f = e1 in assert { J[f,g] }
      
      In absence of an explicit witness, an existential proof obligation
      "exists f,g. J[f,g]" is produced.
      15fc3d65
  2. 11 Jun, 2017 1 commit
  3. 10 Jun, 2017 1 commit
    • Andrei Paskevich's avatar
      Mlw: slightly generalize the rules for overloading · 084211c1
      Andrei Paskevich authored
      A symbol is now considered overloadable if it satisfies
      the following conditions:
        - it has at least one parameter
        - it is non-ghost and has fully visible result
        - all of its parameters are non-ghost and have the same type
        - its result is either of the same type as its parameters
          or it is a monomorphic immutable type.
      
      An overloadable symbol can be combined with other symbols of the
      same arity and overloading kind. Otherwise, the new symbol shadows
      the previously defined ones.
      
      This generalisation allows us to overload symbols such as "size"
      or "length", and also symbols of arbitraty non-zero arity.
      
      I am reluctant to generalize this any further, because then we
      won't have reasonable destructible signatures for type inference.
      084211c1
  4. 09 Jun, 2017 1 commit
  5. 08 Jun, 2017 1 commit
    • Andrei Paskevich's avatar
      Mlw: for-loops over range types · 2f7b69b5
      Andrei Paskevich authored
      In the surface language, the loop index is always int in
      the loop invariant and all annotations and pure terms inside
      the loop. If you want to access the original range-typed index,
      use "let copy_i = i in" in the program code before your assertion.
      Of course, you cannot do that for the loop invariant, which is
      what we want.
      2f7b69b5
  6. 05 Jun, 2017 1 commit
  7. 23 May, 2017 1 commit
  8. 12 May, 2017 2 commits
  9. 11 May, 2017 1 commit
    • Andrei Paskevich's avatar
      Pdecl: split type declarations in chunks · b6e2a7b6
      Andrei Paskevich authored
      Refinement code requires private types to reside in
      separate program declarations. So we split type decls
      into chunks where all non-free types are declared
      separately and only constructible (Ddata) types are
      kept together. The code preserves the original order
      wherever possible.
      
      Also, export ls_of_rs and fd_of_rs from Expr: these are
      used everywhere in src/mlw anyway.
      
      Also, remove some range/float-related "assert false".
      b6e2a7b6
  10. 06 May, 2017 1 commit
  11. 03 May, 2017 1 commit
  12. 23 Apr, 2017 1 commit
  13. 21 Apr, 2017 1 commit
  14. 12 Apr, 2017 1 commit
  15. 28 Feb, 2017 1 commit
    • Clément Fumex's avatar
      Add the ability to · f0547868
      Clément Fumex authored
      * declare range types and float types,
      * use integer (resp. real) literals for those types through casting,
      * specify how to print them in drivers.
      
      Change in syntax
      * use
      
        type t = < range 1 2 >   (* integers from 1 to 2 *)
        type t' = < float 4 12 > (* float with 4 bits in exponent and 12 in mantissa *)
      
        the two projections :
        t'int
        t''real
      
        and the predicate :
        t''isFinite
      
      * Restrict the use of "'" in whyml:
        Users are not allowed to introduce names where a quote symbol
        is followed by a letter. Thus, the following identifiers are
        valid:
      
        t'
        toto'0''
        toto'_phi
      
        whereas toto'phi is not.
      
      Note: we do not yet support negative numbers in range declaration
      and casting of a literal.
      f0547868
  16. 15 Feb, 2017 1 commit
  17. 19 Jan, 2017 1 commit
  18. 17 Jan, 2017 1 commit
  19. 15 Mar, 2016 3 commits
  20. 09 Mar, 2016 1 commit
  21. 08 Mar, 2016 1 commit
  22. 05 Mar, 2016 1 commit
  23. 25 Feb, 2016 1 commit
  24. 24 Feb, 2016 1 commit
  25. 10 Feb, 2016 2 commits
  26. 24 Jan, 2016 1 commit
  27. 17 Jan, 2016 1 commit
  28. 11 Jan, 2016 1 commit
  29. 10 Jan, 2016 1 commit
    • Andrei Paskevich's avatar
      Mlw: allow non-ghost expressions to return (partially) ghost values · 4c79348a
      Andrei Paskevich authored
      this is still work in progress and no testing was done so far.
      
      Highlights of this commit:
      
      - "(ghost 42, 15)" is now a non-ghost expression that can be returned
        from a function and/or matched against a "(ghost x, y)" pattern.
        Only the tuple constructor and direct pattern matching are magical:
        "let z = (ghost 42, 15) in ..." still makes z ghost, and therefore
        "snd (ghost 42, 15)" is ghost, too.
      
      - "if c then e1 else ghost e2" and "let z = e1 in ghost e2" are now
        non-ghost expressions with a ghost result. This means that e1 may
        have visible effects. Of course, if e2 raises exceptions, the whole
        expression is ghostified. Contamination is still done when possible,
        that is, when the contaminated expression has no visible effects.
      
      - "let ghost x = e1 in e2" no longer ghostifies e1.
      
      - "let f (ghost x) = ... in f e1" no longer ghostifies e1.
      
      - new syntax: variables in program patterns may be marked ghost.
        In particular: "let x, ghost y = ...".
      
      - new syntax: the function result type may be written as a partially
        ghost tuple: "val f ... : ghost int" or "any (int, ghost bool)".
        The ghostness annotation is required for top-level and recursive
        functions.
      
      - exceptions can carry partially ghost tuples (API only, WIP)
      4c79348a
  30. 07 Dec, 2015 1 commit
  31. 24 Nov, 2015 1 commit
  32. 15 Nov, 2015 1 commit
    • Andrei Paskevich's avatar
      Mlw: admit fields with mutable types in private records · f522e56e
      Andrei Paskevich authored
      this should not be problematic as long as these fields do not occur
      in the invariants (actual or refined). In other words, a value of
      a private type exists no matter what is stored in the field.
      
      Also, admit non-private mutable types without actual mutable fields.
      It is actually impossible to create a write effect for such types,
      and the only consequence of being mutable is that they are assigned
      a region, and so every value of such type can be tracked individually.
      One use case for this is a non-private record with an invariant,
      which either has fields with mutable types or has type parameters
      that we wish to instantiate with mutable types. If we modify these
      mutable components, this may break the record's invariant. Now, if
      the record itself is immutable (and thus has no associated region),
      then we must reestablish the invariant immediately, otherwise we
      lose track of the value. Even if this extra flexibility does not
      prove useful in the end, it seems to be harmless.
      
      Also, admit type definitions of the form
        type t 'a = (private|abstract)? mutable? {} invariant*
      which define private empty records (even if not declared private).
      
      Also, "type t 'a" is now equivalent to "type t 'a = private {}".
      f522e56e
  33. 08 Nov, 2015 1 commit
  34. 19 Sep, 2015 1 commit
  35. 18 Sep, 2015 1 commit
  36. 21 Aug, 2015 1 commit