 17 Feb, 2016 8 commits


Robbert Krebbers authored

Robbert Krebbers authored
It is doing much more than just dealing with ∈, it solves all kinds of goals involving set operations (including ≡ and ⊆).

Robbert Krebbers authored
simplify_equality => simplify_eq simplify_equality' => simplify_eq/= simplify_map_equality => simplify_map_eq simplify_map_equality' => simplify_map_eq/= simplify_option_equality => simplify_option_eq simplify_list_equality => simplify_list_eq f_equal' => f_equal/= The /= suffixes (meaning: do simpl) are inspired by ssreflect.

Robbert Krebbers authored
The tactic injection H as H is doing exactly that.

Robbert Krebbers authored

Robbert Krebbers authored

Robbert Krebbers authored

Robbert Krebbers authored

 16 Feb, 2016 11 commits


Robbert Krebbers authored
The singleton maps notation is now also more consistent with the insert <[_ := _]> _ notation for maps.

Robbert Krebbers authored

Robbert Krebbers authored

Ralf Jung authored

Ralf Jung authored

Robbert Krebbers authored

Ralf Jung authored

Robbert Krebbers authored

Ralf Jung authored

Ralf Jung authored

Ralf Jung authored

 15 Feb, 2016 2 commits


Robbert Krebbers authored

Ralf Jung authored

 14 Feb, 2016 3 commits


Robbert Krebbers authored

Robbert Krebbers authored

Robbert Krebbers authored

 13 Feb, 2016 3 commits


Robbert Krebbers authored

Robbert Krebbers authored
Also, make our redefinition of done more robust under different orders of Importing modules.

Robbert Krebbers authored
Since Coq 8.4 did not backtrack on eauto premises, we used to ensure that hints like Hint Extern 0 (?x ≡{_}≡ ?y) => reflexivity. were not used for goals involving evars by writing ?x ≡{_}≡ ?y instead of _ ≡{_}≡ _. This seems to be a legacy issue that no longer applies to Coq 8.5, so I have removed these restrictions making these hints thus more powerful.

 11 Feb, 2016 3 commits


Robbert Krebbers authored
Also do some minor clean up.

Robbert Krebbers authored
This reverts commit 24fa20e5. Although these symmetric variants sometimes look "better", they are really annoying and should IMHO never be used: 1.) For lemmas there is now a choice between >= and <=. Since there is no longer a canonical choice, it is very easy to introduce a lot of inconsistencies in statements of lemmas. 2.) For automation the situation becomes annoying, you have to built in stuff for both >= and <=. That is very errorprone. 3.) For N and Z the notions x <= y and y >= x are not even convertible! That means that done/by does not solve x <= y if you have y >= x and if avoids you applying certain lemmas.

Ralf Jung authored

 10 Feb, 2016 1 commit


Ralf Jung authored

 09 Feb, 2016 2 commits


Robbert Krebbers authored

Ralf Jung authored

 08 Feb, 2016 1 commit


Robbert Krebbers authored

 04 Feb, 2016 1 commit


Robbert Krebbers authored

 02 Feb, 2016 1 commit


Ralf Jung authored

 01 Feb, 2016 1 commit


Robbert Krebbers authored

 27 Jan, 2016 1 commit


Ralf Jung authored

 22 Jan, 2016 1 commit


Robbert Krebbers authored

 20 Jan, 2016 1 commit


Robbert Krebbers authored
And use more uniform variable names.
