- 03 Jun, 2017 2 commits
-
-
Andrei Paskevich authored
-
Andrei Paskevich authored
-
- 02 Jun, 2017 5 commits
-
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
Raphael Rieu-Helft authored
-
- 01 Jun, 2017 5 commits
-
-
MARCHE Claude authored
-
MARCHE Claude authored
-
Andrei Paskevich authored
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.
-
Andrei Paskevich authored
-
Martin Clochard authored
(+ élimination de la preuve Coq)
-
- 31 May, 2017 14 commits
-
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
Mário Pereira authored
-
Mário Pereira authored
-
Mário Pereira authored
-
Mário Pereira authored
-
Guillaume Melquiond authored
-
Guillaume Melquiond authored
-
Guillaume Melquiond authored
-
- 30 May, 2017 1 commit
-
-
Mário Pereira authored
-
- 29 May, 2017 2 commits
-
-
Jean-Christophe Filliâtre authored
-
Mário Pereira authored
-
- 27 May, 2017 1 commit
-
-
Andrei Paskevich authored
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.
-
- 25 May, 2017 3 commits
-
-
Andrei Paskevich authored
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.
-
Andrei Paskevich authored
Otherwise, fastWP gets splitted back to classical right away.
-
Andrei Paskevich authored
turns out, Alt-Ergo really dislikes unsplitted premises
-
- 24 May, 2017 6 commits
-
-
MARCHE Claude authored
-
Guillaume Melquiond authored
-
Andrei Paskevich authored
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.
-
Guillaume Melquiond authored
-
Guillaume Melquiond authored
-
Guillaume Melquiond authored
-
- 23 May, 2017 1 commit
-
-
Mário Pereira authored
-