GitLab

As we have to implement the "HERE" and "PARENT" qualifiers anyway,
allowing this shadowing lets us accept more programs without
compromising the "everything is unambigously nameable" invariant.

  (+ élimination de la preuve Coq)

The current syntax is "{| <term> |}", which is shorter than
"pure { <term> }", and does not require a keyword. Better
alternatives are welcome.

As for type inference, we infer the type pf the term under Epure
without binding destructible type variables in the program.
In particular,
  let ghost fn x = {| x + 1 |}
will not typecheck. Indeed, even if we detect that the result
is [int], the type of the formal parameter [x[ is not inferred
in the process, and thus stays at ['xi].

Another problem is related to the fact that variable and function
namespaces are not yet separated when we perform type inference.
Thus both fuctions
  let ghost fn (x: int) = let x a = a in {| x + 5 |}
and
  let ghost fn (x: int) = let x a = a in {| x 5 |}
will not typecheck, since the type of [x] is ['a -> 'a] when
we infer the type for the Epure term, but it becomes [int],
when we construct the final program expression. Probably,
the only reasonable solution is to keep variables and
functions in the same namespace, so that [x] simply can
not be used in annotations after being redefined as a
program function.

We cannot split ite's and matches created in this way,
and it is hard to control how much goes into them.
Try for now to only convert bool-valued ite's.

Otherwise, fastWP gets splitted back to classical right away.

turns out, Alt-Ergo really dislikes unsplitted premises

Prevent introduce_premises from splitting too aggressively
on the left-hand side:

- under quantifiers:
    "forall x. P /\ Q" =/=> "(forall x. P) /\ (forall x. Q)"

- match-with:
    "match t with A -> P | B -> Q" =/=> "(t = A -> P) /\ (t = B -> Q)"

- if-then-else:
    "if f then P else Q" =/=> "(f -> P) /\ (not f -> Q)"

- equivalence:
    "P <-> Q" =/=> "(P -> Q) /\ (Q -> P)"

Those splits duplicate formulas, hinder readability and do not
really simplify anything. Moreover, in case of a split under
a quantifier, they create several universal premises for provers
to instantiate, instead of just one.

TODO: introduce_premises should be able to split under
a single-branch match. However, this requires special
treatment in Introduce.dequant, since the pattern
should be rather skolemized than used as a condition.