Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(library/init/meta/*): port rename tactic from mathlib #205

Merged
merged 2 commits into from May 1, 2020
Merged

Conversation

JLimperg
Copy link
Collaborator

This PR ports the rename interactive tactic from mathlib (with some additional improvements). Features over current core rename:

  • Multiple hypotheses can be renamed at once.
  • The order of hypotheses doesn't change.
  • If there are multiple hypotheses with the same name in the context, they are all renamed.

Breakage in mathlib:

  • Remove rename and list.after (now in core).
  • Fix one proof that relies on edge case behaviour of old rename when there are multiple hypotheses with the same name.

We reimplement the interactive `rename` tactic. The new tactic has the
following features:

- Multiple hypotheses can be renamed at once.
- The order of hypotheses doesn't change.
- If there are multiple hypotheses with the same name in the context,
  they are all renamed.

This tactic was previously implemented in mathlib.

To facilitate the implementation, we also port `list.after` from
mathlib.
@JLimperg
Copy link
Collaborator Author

Sorry, just found a bug in nu-rename. Don't review/merge yet.

`tactic.rename_many` can select the hypotheses to be renamed by unique
names. When using this mode, it would erroneously change the display
name of any hypothesis that was not renamed to its unique name.
@JLimperg
Copy link
Collaborator Author

Okay, now it's at least less obviously buggy.

meta def revertible_local_context : tactic (list expr) :=
do ctx ← local_context,
frozen ← frozen_local_instances,
pure $
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this different from ctx.drop (frozen_local_instance.get_or_else []).length?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so, yes. Your version drops as many hyps from the context as there are frozen instances. However, we can have other hyps in between the frozen instances, so the part of the context that we can't touch can be longer.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's my question: is this possible?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, here's a full test case where the implementations diverge.

namespace list

def after {α} (p : α → Prop) [decidable_pred p] : list α → list α
| [] := []
| (x :: xs) := if p x then xs else after xs

end list

namespace tactic

meta def revertible_local_context₁ : tactic (list expr) :=
do ctx ← local_context,
   frozen ← frozen_local_instances,
   pure $
     match frozen with
     | none := ctx
     | some [] := ctx
     | some (h :: _) := ctx.after (eq h)
     end

meta def revertible_local_context₂ : tactic (list expr) :=
do ctx ← local_context,
   frozen ← frozen_local_instances,
   pure $ ctx.drop $ (frozen.get_or_else []).length

meta def interactive.test : tactic unit :=
do revertible_local_context₁ >>= trace,
   revertible_local_context₂ >>= trace

end tactic


lemma test {α : Prop} [decidable α] {β : Prop} [decidable β] : unit :=
begin
  test,
  exact ()
end

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so frozen_local_instances only returns the instances.

@@ -665,7 +684,9 @@ private meta def find_case (goals : list expr) (ty : name) (idx : nat) (num_indi
end else none

private meta def rename_lams : expr → list name → tactic unit
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like rename_lams should be reimplemented using rename_many and rename_unstable should be removed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! That'll be the case tag PR which I'm working on, and which this PR is leading up to.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@gebner gebner merged commit b63deda into master May 1, 2020
@JLimperg
Copy link
Collaborator Author

JLimperg commented May 1, 2020

Thanks for the review!

@JLimperg JLimperg deleted the rename branch May 1, 2020 20:51
@gebner
Copy link
Member

gebner commented May 2, 2020

How do you use this tactic to rename multiple variables with the same name?

example (x x : ℕ) : ... :=
begin
  rename ???
end

@digama0
Copy link
Member

digama0 commented May 2, 2020

Hopefully that just names the second one. If you have this situation, you can call dedup first, but otherwise the first x is basically inaccessible, which is the point of name shadowing.

@JLimperg
Copy link
Collaborator Author

JLimperg commented May 2, 2020

No, rename x y will rename both xs. I didn't want to complicate the tactic even more to support a fringe case. (In all of mathlib, there was only one proof that relied on the 'rename only the last occurrence' semantics, and this was easy to solve using dedup as you point out.)

rename' x y -- rename x to y
rename' x → y -- ditto
rename' [x y, a b] -- rename x to y and a to b
rename' [x → y, a → b] -- ditto
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should be rename.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I just noticed that as well. :( I'll write a doc PR.

@bryangingechen bryangingechen mentioned this pull request May 4, 2020
12 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants