1. 27 Jun, 2015 1 commit
  2. 24 Jun, 2015 2 commits
  3. 20 Mar, 2015 1 commit
  4. 19 Mar, 2015 1 commit
  5. 22 Oct, 2014 1 commit
  6. 20 Sep, 2014 1 commit
  7. 07 Apr, 2014 1 commit
  8. 14 Mar, 2014 1 commit
  9. 12 Feb, 2014 1 commit
  10. 20 Jan, 2014 1 commit
    • Andrei Paskevich's avatar
      WhyML: add "diverges", "reads {}", and "writes {}" effect clauses · 83858597
      Andrei Paskevich authored
      - "diverges" states that the computation may not terminate (which
        does not mean that is always diverges: just as any other effect
        annotation, this clause states a possibility of a side effect).
      
      - "reads {}" states that the computation does not access any variable
        except those that are listed elsewhere in the specification (or the
        proper function arguments, if "reads" is in a function spec).
      
      - "writes {}" states that the computation does not modify any mutable
        value.
      
      - If a function definition or an abstract computation may diverge,
        but there is no "diverges" clause in the specification, a warning
        is produced. If a function definition or an abstract computation
        always terminates, but there is a "diverges" clause in the spec,
        an error is produced.
      
      - If there is a "reads" or a "writes" clause in a function definition
        or an abstract computation, then every modified value must be listed
        in "writes" and every accessed external variable not mentioned in
        the spec must be listed in "reads". (Notice that this is a stricter
        requirement than before, when the presence of a "writes" clause
        did not require to specify "reads".) However, one does not have to
        write "reads {}" or "writes {}" if the corresponding lists are empty.
      83858597
  11. 24 Nov, 2013 1 commit
  12. 20 Nov, 2013 2 commits
  13. 19 Nov, 2013 4 commits
  14. 19 Oct, 2013 1 commit
    • Andrei Paskevich's avatar
      switch Typing to the new Dterm-based API · 460e93f8
      Andrei Paskevich authored
      Also:
      
      - Make [Highord.pred 'a] an alias for [Highord.func 'a bool],
      rename [Highorg.(@!)] to [(@)], remove [Highorg.(@?)], remove
      the quantifiers [\!] and [\?] and only leave [\] which is the
      only true lambda now;
      
      - Allow mixing bool and Prop in logic, Dterm will introduce
      coercions where necessary (trying to minimize the number of
      if-then-else in the term context).
      460e93f8
  15. 25 Apr, 2013 1 commit
    • Andrei Paskevich's avatar
      whyml episode VI: the return of read effects · b4caa997
      Andrei Paskevich authored
      By popular demand, read effects are back. They serve to mark dependence
      of a program function on external variables which are otherwise not
      mentioned in the function's specification. Such annotation is necessary,
      for example, to add the needed type invariants.
      
      The "reads" clauses are comma-separated variables (contrary to write
      effects, where one must point out the modified field).
      
      If a user specifies a "reads" clause for a defined function, we check
      that every listed variable occurs in the code and that every free
      variable in the code occurs in the specification (which includes the
      "reads" clause). Notice that this concers function arguments, too:
      
        val r : ref int
        let f (x : ref int) reads {r} = x := !r
      
      would require x to be added to reads.
      b4caa997
  16. 07 Apr, 2013 1 commit
  17. 22 Mar, 2013 1 commit
    • Jean-Christophe Filliâtre's avatar
      lemma functions · 3a716828
      Jean-Christophe Filliâtre authored
      a lemma function is introduced with 'let lemma f' or 'let rec lemma f'
      it is a ghost function
      it must have return type unit and read-only effects
      it introduces a goal (its WP), followed by an axiom
        forall args/reads, precondition => postcondition
      3a716828
  18. 06 Mar, 2013 1 commit
  19. 03 Mar, 2013 1 commit
    • Andrei Paskevich's avatar
      track dangerous applications of equality · bb6734a1
      Andrei Paskevich authored
      In programs, but also in pure theories, it is not safe to compare
      arbitrary types. For example, if we have a record with ghost fields,
      a comparison may produce different results before and after ghost
      code elimination. Even for pure types like 'map' or 'set', it is
      unlikely that the result of logical equality will be the same as
      the result of OCaml structural equality on the implemented type.
      
      This commit makes the first step towards fixing this issue.
      We proceed in the following way:
      
      1. Every lsymbol (pure function or predicate symbol) carries
         a subset of type variables of its signature, called "opaque
         type variables". By marking a type variable 'a opaque in an
         lsymbol's signature, the user guarantees that this lsymbol
         can be implemented without ever comparing values of type 'a.
         In other words, this is a promise not to break into a type
         variable.
      
         The corresponding syntax is: "predicate safe (x y : ~'a)".
      
         All type variables in undefined symbols are non-opaque,
         unless annotated otherwise. Non-opaque is the default
         to keep the change conservative.
      
         Opacity of type variables in defined symbols is inferred
         from the definition. If the definition violates a given
         opacity annotation, an exception is raised. Notice that
         we only check definitions in _theory_ declarations. One
         can define an lsymbol in a _task_ in a way that violates
         opacity. We cannot forbid it, because various elimination
         transformations would replace safe operations (such as
         matching) with equalities. This is not a problem, since in
         the pure logical realm of provers opacity is not required
         One exception would be Coq, whose transformation chain must
         never perform such operations.
      
         All type variables in inductive predicates are non-opaque.
         Indeed, we can redefine equality via an inductive predicate.
         [TODO: find safe forms of inductive definitions and implement
         more reasonable restrictions.]
      
         All type variables in constructors and field symbols are opaque.
      
         It is forbidden to instantiate an opacity-preserving symbol
         with an opacity-breaking one in a clone substitution.
      
      2. Similar type variable tracking is implemented for program symbols.
         Type variables in the signature of a "val" are non-opaque unless
         annotated otherwise. Opacity of type variables in defined symbols
         is inferred from the definition, and an exception is raised, if
         a given annotation is violated.
      
         The internal mechanism of tracking is different: the "eff_compar"
         field in effects contains the type variables that occur under
         equality or any other opacity-breaking operation. In this respect,
         our API is inconsistent between lsymbols and psymbols: the former
         asks for the opaque tvsymbols, the latter requires us to fill the
         spec with "comparison effects" for the non-opaque ones. [TODO:
         add the "~opaque" argument to create_psymbol and make the WhyML
         core fill the effect under the hood.]
      
         Every time an lsymbol or a psymbol is applied in a program,
         we check the substitution into its signature's type variables.
         If a non-opaque type variable is instantiated with a program type,
         an exception is raised. [TODO: be more precise and reject only
         types with ghost and model components - being mutable, private,
         or carrying an invariant doesn't conflict with equality.]
      
         Notice that we do not allow to compare program types even in
         the ghost code. This is not needed if we only consider the
         problems of the code extraction, but _might_ be necessary,
         if we also want to protect Coq realisations (see below).
      
      This commit fixes the immediate problem of breaking the ghost
      guarantees when equality or some other opacity-breaking lsymbol
      is applied in a program to a type with ghost or "model" parts.
      
      This leaves the problem of code extraction for programs that
      compare complex types such as maps or sets (Coq driver is
      affected by this, too, I guess). The next step is to provide
      annotations for problematic type constructors. A declaration
      "type ~map 'a 'b" would mean "logical equality on this type
      is likely to be different from the structural equality on any
      implementation of this type - therefore do not apply equality
      to it: neither in programs (because this can't be implemented),
      nor in pure functions (because they are extracted, too, and
      because this can't be realized with Leibniz equality in Coq)."
      [TODO: discuss and implement.]
      
      [TODO: mb choose better term for "opaque" and notation for ~'a.]
      bb6734a1
  20. 17 Feb, 2013 1 commit
    • Andrei Paskevich's avatar
      unify the syntax of binders in logic and programs · ac5e027d
      Andrei Paskevich authored
      Also, ghost fields in algerbraic types are now accepted in programs.
      
      As of now, "function", "predicate", "inductive", "val", "let", "fun",
      and constructors in algebraic type declarations all accept the same
      syntax for parameters. In "function", "predicate", "inductive", "val",
      and constructors in algebraic type declarations, binders without
      colons are treated as type expressions:
      
          function f int (list bool) (int,real) (ghost bool)
      
      is syntactic sugar for
      
          function f (_: int) (_: list bool) (_: (int,real)) (ghost _: bool)
      
      In "let" and "fun", single unqualified idents are treated as parameter
      names whose types are to be inferred, other binders without colons are
      treated as type expressions:
      
          let f int (list bool) (int,real) (ghost bool)
      
      is syntactic sugar for
      
          let f (int: ?) (_: list bool) (_: (int,real)) (ghost bool: ?)
      
      Anonymous binders ("_") are accepted only if their type is specified.
      ac5e027d
  21. 09 Feb, 2013 1 commit
    • Andrei Paskevich's avatar
      whyml: accept infix relation chains · 919d60bf
      Andrei Paskevich authored
      In a chain "e1 op1 e2 op2 e3 op3 e4", each relation symbol is either:
      
      - an infix symbol "=" or "<>", or
      
      - a binary symbol whose value type is Bool.bool or Prop (for lsymbols)
        and whose arguments' types are not Bool.bool.
      
      In other words, we interpret a chain as a conjunction only if there
      is no possibility(*) to interpret it as a superposition. The exception
      is only made for "=" and "<>", which are _always_ considered as
      chainable, even if they are redefined with some bogus type signatures.
      Notice that redefining "<>" has no effect whatsoever, since "<>" is
      always treated as negated "=".
      
      As for the evaluation order, the chain above would be equivalent to:
          let x2 = e2 in
          (e1 op1 x2) &&
              let x3 = e3 in
              (x2 op2 x3) &&
                  (x3 op3 e4)
      This is due to the fact that lazy conjunctions are evaluated from
      left to right, function arguments are evaluated from right to left,
      and no expression should be evaluated twice.
      
      [*] well, not really, since we consider symbols ('a -> 'b -> bool)
      as chainable, even though such chains could be interpreted as
      superpositions(**). We could treat such symbols as unchainable,
      but that would make equality and disequality doubly special cases,
      and I don't like it. We'll see if the current conditions are not
      enough.
      
      [**] what also bothers me is dynamic types of locally defined
      infix symbols, which can be type variables or Bool.bool depending
      on the order of operations in Mlw_typing. Currently, I can't come
      up with any example of bad behaviour -- we are somewhat saved by
      not being able to write "let (==) = ... in ...").
      919d60bf
  22. 05 Feb, 2013 2 commits
  23. 18 Jan, 2013 1 commit
  24. 24 Dec, 2012 1 commit
  25. 19 Dec, 2012 1 commit
  26. 06 Nov, 2012 1 commit
  27. 20 Oct, 2012 1 commit
    • Andrei Paskevich's avatar
      simplify copyright headers · 11598d2b
      Andrei Paskevich authored
      + create AUTHORS file
      + fix the linking exception in LICENSE
      + update the "About" in IDE
      + remove the trailing whitespace
      + inflate my scores at Ohloh
      11598d2b
  28. 12 Oct, 2012 1 commit
  29. 06 Oct, 2012 1 commit
  30. 04 Oct, 2012 1 commit
  31. 01 Oct, 2012 1 commit
  32. 22 Sep, 2012 1 commit
  33. 05 Aug, 2012 2 commits