Une MAJ de sécurité est nécessaire sur notre version actuelle. Elle sera effectuée lundi 02/08 entre 12h30 et 13h. L'interruption de service devrait durer quelques minutes (probablement moins de 5 minutes).

  1. 23 Mar, 2013 1 commit
  2. 04 Mar, 2013 1 commit
    • Andrei Paskevich's avatar
      whyml: match expression is ghost if we look inside ghost fields · 43b684d0
      Andrei Paskevich authored
      We store in every lsymbol a new integer field ls_constr,
      equal to zero if the lsymbol is not a constructor, and equal
      to the number of constructors of the lsymbol's type otherwise.
      It is allowed to declare or define an lsymbol with ls_constr > 0
      as an ordinary function (otherwise algebraic type elimination
      wouldn't work - though we might still check this in theories),
      but it is forbidden to use a wrong ls_constr in algebraic type
      The ghostness of a match expression is now determined as follows:
      If at least one branch expression is ghost,
        then the match is ghost;
      else if there is only one branch,
        then the match is not ghost;
      else if the matched expression is ghost,
        then the match is ghost;
      else if at least one pattern matches a ghost field
              against a constructor with ls_constr > 1
        then the match is ghost;
        the match is not ghost.
      We do just enough to recognize obvious non-ghost cases, and
      make no attempt to handle redundant matches or to detect
      exhaustive or-patterns in subpatterns.
  3. 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
         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.]
  4. 18 Feb, 2013 1 commit
  5. 03 Feb, 2013 1 commit
  6. 30 Jan, 2013 2 commits
    • Andrei Paskevich's avatar
      minor fix to the previous commit · fd0729a6
      Andrei Paskevich authored
    • Andrei Paskevich's avatar
      reorganize examples/ · 4b1bc2b0
      Andrei Paskevich authored
      - all programs with sessions are in examples/
      - all programs without sessions are in examples/in_progress/
        (if you have private sessions for those, just move them there)
      - all pure logical problems are in logic/
        (to simplify bench scripts and gallery building; they are few anyway)
      - all OCaml programs are in examples/use_api/
      - all strange stuff is in examples/misc/
        (most of it should probably go)
      - Claude's solutions for Foveoos 2011 are in examples/foveoos11-cm/
        (why do we need two sets of solutions for quite simple problems?)
      - hoare_logic, bitvectors, vacid_0_binary_heaps are in examples/
      Bench scripts and documentation are updated.
      Also, bench/bench is simplified a little bit.
  7. 30 Oct, 2012 1 commit
  8. 12 Oct, 2012 1 commit
  9. 04 Sep, 2012 1 commit
  10. 03 Sep, 2012 1 commit
  11. 16 Aug, 2012 1 commit
  12. 04 Aug, 2012 1 commit
  13. 03 Aug, 2012 2 commits
    • Jean-Christophe Filliâtre's avatar
      no more why3ml executable · 56c1047c
      Jean-Christophe Filliâtre authored
    • François Bobot's avatar
      Documentation: add description to all the registration functions · 29201f7c
      François Bobot authored
       (metas, debug flags, transformations, formats) except for label.
      This description is used in --list-*. The description can use any of
      the formatting markup of Format "@ " "@[",...
      Transformations can also specify from which metas and labels they
      depend, and add informations about how they are interpreted.
        - complete and correct the documentation
        - when a transformation use Trans.on_meta, it should be possible to
          add an interpretation of the metas in the documentation.
        - recover a summary version of --list-* ?
        - be able to export in latex?
  14. 02 Aug, 2012 1 commit
  15. 23 Jul, 2012 2 commits
    • François Bobot's avatar
      prover identification: use shortcuts · 92165a83
      François Bobot authored
         shortcuts are defined in why3.conf. They are automatically
         generated using two mechanism:
         - a shortcut section in prover-detection-data.conf creates a shortcut
         for the first prover that match the regexp
         - the identifier used as family argument for the prover section in
         prover-detection-data.conf is used as shortcut for the prover. If
         different sections use the same argument the first one that match an
         existing prover is used for the shortcut.
    • François Bobot's avatar
      new prover identification: remove id · 5a3641ec
      François Bobot authored
             Remove the id in prover that is used only for command-line, use
             instead the name,version,alternative of the prover. One can
             also use regular expression (start with ^).
             "Alt-Ergo,0.92,with arrays" corresponds only to one prover
             "Alt-Ergo,^0\.9.*,with arrays" correspond to all the Alt-Ergo prover with arrays which version match "0\.9.*"
             "Alt-Ergo" is the same thing than "Alt-Ergo,^,^"
             "Alt-Ergo,0.92," corresponds only to one prover with the alternate fields empty
             "Alt-Ergo,,with arrays" corresponds to "Alt-Ergo,^,with arrays" since the version is never empty.
             Provers identification are case sensitive even if it is
             currently more complicated for the user because
             case-insensitiveness is not sufficient. Specifiying "alt-ergo"
             for "Alt-Ergo,^,^" is great, but not if there is more than one
             match. A more general system of shortcut would be more
  16. 20 Jul, 2012 1 commit
  17. 13 Jul, 2012 1 commit
  18. 12 Jul, 2012 1 commit
  19. 23 Jun, 2012 1 commit
  20. 14 Apr, 2012 1 commit
  21. 03 Feb, 2012 2 commits
  22. 20 Sep, 2011 1 commit
  23. 14 Sep, 2011 1 commit
  24. 02 Sep, 2011 1 commit
  25. 11 Aug, 2011 1 commit
  26. 04 Aug, 2011 1 commit
  27. 13 Jul, 2011 1 commit
    • Guillaume Melquiond's avatar
      Add support for generic printing of integers and reals. · 1ba8f1a6
      Guillaume Melquiond authored
      Prover capabilities are now represented by a record enumerating each case and which syntax to use then.
      This fixes output of nondecimal integers to provers (bug #12981).
      TODO: check whether some provers support more than just decimal representations.
  28. 11 Jul, 2011 1 commit
  29. 07 Jul, 2011 1 commit
  30. 05 Jul, 2011 1 commit
  31. 04 Jul, 2011 2 commits
  32. 01 Jul, 2011 2 commits
  33. 30 Jun, 2011 1 commit
  34. 29 Jun, 2011 1 commit
    • Andrei Paskevich's avatar
      several changes in syntax · aa2c430e
      Andrei Paskevich authored
      - No more "and", "or", "implies", "iff", and "~".
        Use "/\", "\/", "->", "<->", and "not" instead.
      - No more "logic". Use "function" or "predicate".