The tactic_state object will contain a name_generator for creating fresh
names. `tactic_state.mk_empty` is bad because it does not have sufficient
information to create this name_generator.
Moreover `tactic_state.mk_empty` was only being used to convert
`tactic A` into a `parser A`.
We implement this primitive now in C++. In C++, we will be able
to use the parser name generator to initialize a fresh `tactic_state`.
The tactic `mk_fresh_name` is used to create internal unique ids.
We should not use them to create (temporary) user facing
names. Reasons:
1- They are "cryptic".
2- They are not very stable. Minor changes in Lean may change the
value returned and may break proofs that rely on these fresh names.
This command is not just a cosmetic feature.
We need it to defined `id_rhs` before the tactic framework is defined.
We want `id_rhs` to be used in all definitions generated by the equation
compiler. Right now, it is only used in definitions defined after the
tactic framework.
Now tactics supporting locations can also specify the goal among the locations by using the name `⊢` or `|-`. Also `rw at *` is implemented so that it will rewrite any hypotheses or the goal for which the whole sequence of rewrites succeeds. (This is different from `rw at h1 h2 ... hn |-`, which requires that all rewrites run to completion on each specified target.)
and all/any_goals. This occurs when solving the first subgoal generated by `tac1; tac2` closes the second goal as well, before the second `tac2` invocation is run. Reported by @jldodds on gitter.
Before this commit, the `by_cases p` tactic would synthesize
`inst : decidable p` type class resolution, and then use the
`cases` tactic (dependent elimination). This would create
problems since occurrences of `inst` would be replaced with
`decidable.is_true h` in one branch, and `decidable.is_false h` in the
other. Where `h`s (we have two of them, one for each branch) are
fresh hypotheses introduced by the `cases` tactic.
For example, assume we have the term in our goal.
`@ite p inst A a b`
This term would become
`@ite p (decidable.is_true h) A a b` (in the first branch where `h : p`)
and
`@ite p (decidable.is_false h) A a b` (in the second where `h : not p`)
Now, suppose we try to executed the following tactic in the first branch
`rw [if_pos h]`
it will fail since `if_pos h` is actually `@if_pos p inst h`, and
we will not be able to unify
`@ite p (decidable.is_true h) A a b =?= @ite p inst ?A ?a ?b`
This commit workarounds this problem by applying cases on
`@decidable.em p inst : p or not p` instead of `inst : decidable p`.
Thus, the term `inst` is not replaced with `decidable.is_true h` and
`decidable.is_false h`.
The new test `tests/lean/run/simp_dif.lean` demonstrates the problem above.
It now performs self simplification, and the performance is slightly
better. As described at issue #1675, only non dependent propositions
are considered.
@Armael: this tactic may be useful for you
`rewrite` tactic improvements
- Add support for `auto_param` and `opt_param`
- Order new goals using the same strategies available for `apply`
- Allow user to set configuration object in interactive mode.
@Armael This commit should address the issue you raised about the order
of new goals in the `rewrite` tactic.
See new test tests/lean/run/rw1.lean for examples.
