TODO

library/gallery migration
-------------------------

  - check that examples/tests/cvc4-models.mlw can use arrays
    instead of ref map (commit dfc90d)

  - remove the temporary --type-only from bench/bench (commit 02be08f)

  - DISCUSS: why3 prove theories/int.why fails because of a "variant"
    clause in one of let functions: this clause requires int.Int
    for the order relation, which is not loaded automatically
    (program modules are expected to do "use import int.Int")
    and, of course, cannot be used explicitly inside int.why.

  - expression { e with f2 = e2 } is syntactic sugar for
    { f1 = e.f1; f2 = e2; f3 = e.f3 }
    We would get better error messages if we would produce instead
    { f2 = e2; f1 = e.f1; f3 = e.f3 }
    that is, with user-given fields first, then fields from e
    See for instance bench/programs/bad-typing/with1.mlw

  - the error message for
      val foo (_x : int) : int
      val f (x:int) : unit writes { foo.contents }
    is "unbound symbol 'foo'", which is not correct
    (is should rather be that "foo" has the wrong type)

  - bench/programs/bad-to-keep/{at1.mlw,old2.mlw}
    should at least produce a warning (meaningless 'old')

  - no warning on lemma functions
    cf examples/tests/lemma_functions.mlw

  - "old" and "at" in program code gives a syntax error
    (bench/programs/bad-to-keep/old3.mlw), we can do better

docs
----

  - rename the languages to "Why" and "WhyML". "Why3ML" is a horrible name.

generic
-------

  - let modules register new command-line options. This would deprecate
    the "stop flags" in Debug, and serve, for instance, for --type-only,
    --parse-only, ocaml code extraction, printing of modules, etc.

  - introduce a dedicated buffer-backed formatter for warnings.
    The contents of the buffer would be shown on stdout or in a window
    at selected points of program execution. Demote non-critical errors
    (e.g. unnamed type variables) to warnings.

  - should we create a common [exception Why.Error of exn] to facilitate
    integration of the library? This would require a special [raise] call:
        why_raise e = raise (Why.Error e)

  - the drivers cannot deal with theories defined in the .mlw files.
    Otherwise why3 would report an error. Is it acceptable?

WhyML
-----

  - introduce logic predicates for program type invariants:
      predicate <type_name>_invariant (result : <type_name>) = ...
    Should this be just the top invariant, as written by the user,
    or should we also include the invariants for the fields?

  - allow to specify type invariants below a type definition,
    provided there are no program declarations in between.
    This allows us to define auxiliary logical functions and
    predicates that depend on the (pure) type and can be used in
    the invariant. However, the parser must know from the start
    that the type has an invariant, what's the best syntax?

  - type invariants are now assumed/asserted at the function call
    boundaries. We can add a binary flag to Ityapp to allow open
    types in function signatures (must be careful with reg_match!).
    The type cast can then play the role of the "close" instruction.
    Do we need it? What's the good syntax for open types?

  - we check the context type invariants around Eany and after Eabstr.
    It might be strange that Eabstr post-ensures the invariants that
    didn't necessarily hold before its execution. Also, what about
    return/raise invariants, should Eany and Eabstr enforce them?
    (at the moment, they do)

  - currently every unhandled exception has the postcondition "true".
    "false" would be a poor choice, as it could introduce inconsistency
    in the WPs of the caller. Should we allow unhandled exceptions at all?

  - current WP does not respect the lexical scope. In the program

      let r = create 0 in
      let v = !r in
      incr r;
      let () =
        let v = !r in
        ()
      in
      assert { v = 1 }

    the last assert will be proven if the same let_defn [let v = !r]
    and therefore the same pvsymbol v is used in both places (which
    can be done using API). One possible solution is to ensure the
    one-time usage of let_defns and rec_defns in programs.

  - are mutable values worth it? They can only appear as pattern
    variables standing for mutable fields, and allow us to have
    mutable fields in algebraic types. On the other hand, they
    require tedious checks pretty much everywhere in the code,
    and they cannot be translated to OCaml.

  - accept match e1 with pat -> e2 end as non-ghost when e1 is ghost
    and e2 is not ghost

syntax
------

  - open

  - infix symbols as constructors, e.g.

       type list 'a = Nil | (::) 'a (list 'a)

  - constants in patterns, e.g.

       match ... with 0 :: r -> ... | ...

semantics
---------

  - should split_goal provide a "right-hand side only split"?

  - produce reparsable tasks in Why3 format: how to preserve information about
    the origins of symbols to be able to use drivers after reparsing?

  - open (et échouer si "open A" et "open B" avec A et B déclarant un symbole
    de même nom)

session
-------

  - save the output of the prover

  - escape the string in the xml

  - the filenames in the location inside a session should be relative
    to the session_dir.

  - use the new restore_path for the metas in session?

tools
-----

  - the tools should verify that the provers have the same version
    than reported in the configuration
        Andrei: isn't this done?

  - Maybe : make something generic for the dialog box with memory.


OCaml extraction
----------------

  - allow other realizations for arithmetic, such as Zarith or GMP
    (currently this is Num)

  - avoid conversion to/from int in the for-loop

  - driver
    - %Exit -> Pervasives.Exit

provers
-------

  - PVS: use a better name for PVS theory when printing a task, e.g.
    file_theory_goal. Solution: do that when we have idents with origin
    information (necessary for parsing a task).