1. 15 Feb, 2014 2 commits
  2. 14 Feb, 2014 4 commits
    • MARCHE Claude's avatar
    • Andrei Paskevich's avatar
      WhyML: change the syntax of "abstract" · 4fd8b24d
      Andrei Paskevich authored
      The old syntax:   abstract expr [spec]...
      The semicolon binds more loosely than "abstract" and
      the specification clauses are optional, so that
      "abstract e1; e2" is the same as "(abstract e1); e2"
      and "abstract e1; e2; ensures {...}" is a syntax error.
      The new syntax:   abstract [spec]... expr end
      This allows to put sequences of expressions under "abstract"
      without ambiguity and moves the specification clauses to the
      beginning. In other words, "abstract" becomes a "begin" with
      a specification attached. The spec-at-the-top is consistent
      with the syntax of functions and the whole seems to be more
      natural for the intented use of "abstract" (a logical cut).
    • Andrei Paskevich's avatar
      WhyML: admit terminating semi-colons when there is no ambiguity · e66e2a3f
      Andrei Paskevich authored
        begin ... expr; end
        let fn x y = ... expr ; in ...
        match ... with pat -> ... expr ; | pat -> ... expr ; end
      In this way, it's much easier to add and remove additional
      assertions at the end of ()-typed blocks.
    • Andrei Paskevich's avatar
  3. 13 Feb, 2014 1 commit
  4. 12 Feb, 2014 4 commits
  5. 11 Feb, 2014 4 commits
  6. 07 Feb, 2014 1 commit
  7. 06 Feb, 2014 1 commit
  8. 04 Feb, 2014 1 commit
  9. 03 Feb, 2014 3 commits
  10. 01 Feb, 2014 1 commit
  11. 30 Jan, 2014 1 commit
  12. 28 Jan, 2014 5 commits
  13. 27 Jan, 2014 2 commits
  14. 22 Jan, 2014 4 commits
    • Andrei Paskevich's avatar
      IDE: save a few clicks when expanding sub-trees · 2ac8e77f
      Andrei Paskevich authored
      The following rules are added:
      - When expanding a goal, expand every transformation and "metas"
        attached to this goal. Usually, we have at most one transformation
        or "metas": the one which hopefully leads us to the proof. Even
        if we have several transformations applied to the same goal,
        their number is quite limited (split, inline, bisect, what else?),
        so why not open them all? And now, at last, we don't have to click
        for the second time on "split_goal_wp" to see the result of a split.
      - When expanding a transformation that has a single resulting goal,
        expand that goal, too. Now, when I expand a goal and see that the
        "inline" transformation was applied, I see immediately how the
        resulting goal was handled.
      - When expanding a "metas" line, expand the resulting goal, too.
        Once again, if a manipulation gives us one goal as a result,
        there is not much information in that, unless we see how that
        new goal was dealt with.
    • Andrei Paskevich's avatar
    • Andrei Paskevich's avatar
      minor change in error message · f9682a1c
      Andrei Paskevich authored
    • Andrei Paskevich's avatar
      fastwp: bugfix · 7ee0bf01
      Andrei Paskevich authored
      Submitted by Johannes Kanig
  15. 21 Jan, 2014 4 commits
  16. 20 Jan, 2014 2 commits
    • Andrei Paskevich's avatar
      minor English grammar fix · dff7079b
      Andrei Paskevich authored
    • Andrei Paskevich's avatar
      "eliminate_epsilon" added in drivers · 9c20cd7c
      Andrei Paskevich authored
      Currently, the builtin theory why3.HighOrd (or just HighOrd) must
      be explicitly "use"-d. However, the type (HighOrd.func 'a 'b) can
      be written ('a -> 'b), and the type (HighOrd.pred 'a) can be written
      ('a -> bool), and the application operation (HighOrd.(@)) can be
      written as the usual juxtaposition. Thus, normally, you do not have
      to write the qualifiers. The builtin theory why3.Bool (or just Bool)
      is needed for "bool". The names "HighOrd", "func", "pred", and "(@)"
      are not yet fixed and may change.
      "eliminate_epsilon" tries to be smart when a lambda (or some other
      comprehension form) occurs under equality or at the top of a definition.
      We could go even further and replace (\ x . t) s with t[x <- s], without
      lifting the lambda. I'm not sure it's worth it: we rarely write redexes
      manually. They can and will appear through inlining, though.
      Anyone who wants to construct epsilon-terms directly using the API
      should remember that these are not Hilbert's epsilons: by writing
      an epsilon term, you postulate the existence (though not necessarily
      uniqueness) of the described object, and "eliminate_epsilon" will
      happily convert it to an axiom expressing this existence. We only
      use epsilons to write comprehensions whose soundness is guaranteed
      by a background theory, e.g. lambda-calculus.