This feature is needed when we declare an inductive predicate/type
which is indexed by a mutual and/or nested inductive datatype.
See tests/lean/run/term_pred.lean for an example.
@Armael: this commit should fix the issue with the `cases` tactic that
you reported today.
See issue #1175
BTW, we may have to revise this decision in the future when we decide to
populate the string library with lemmas.
It is inconvenient to prove the lemmas at string/basic.lean since the
tactic framework has not been defined yet.
Anyway, I think it is worth to keep the private for now, and make sure
nobody relies on its implementation.
We want to make sure string users do not depend on the string
implementation. This is the first step.
We need this refactoring *now* to make sure it will not be
super painful to address issue #1175
@Armael: the new file `tests/lean/run/add_interactive.lean` contains a
small example. Note that we don't have auto quotation for commands yet.
So, I have to use the backtick in the example.
@Kha: this is a good candidate for the future command parser extensions.
They can be used to store user state in the tactic_state object.
@Armael @jroesch: The new file tests/lean/run/tactic_ref.lean contains a few examples.
closes#1634
This commit also changes the semantic of `tactic.focus [tac_1, ..., tac_n]`.
It now fails if the number of goals is not `n`.
Before it would only fail if there were more tactics than goals.
@Armael: See tests/lean/run/handthen.lean for examples of the new notation.
@kha @gebner I added the `show_goal` tactic for selecting arbitrary
subgoals. This feature is similar to the one available in Isabelle.
This commit allows us to use the `show` keyword as syntax sugar for
`show_goal`. The test `show_goal.lean` has a small example.
What do you think?
@Armael: you can use `show` to structure your proofs in tactic mode.
See `tests/lean/run/show_goal.lean` for a small example.
This commit fixes issue #1631. However, it is not a perfect solution.
This commit improves the predicate that checks whether a definition is
noncomputable or not. This predicate was implemented before we had
a code generator.
We should refactor the code and use the code generator to check
whether a definition is noncomputable or not. Otherwise, we will
keep finding mismatches between the predicate at noncomputable.cpp
and what the code generator implements.
