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

calc tactic resolves notation incorrectly #651

Closed
1 task
eric-wieser opened this issue Nov 16, 2021 · 3 comments
Closed
1 task

calc tactic resolves notation incorrectly #651

eric-wieser opened this issue Nov 16, 2021 · 3 comments

Comments

@eric-wieser
Copy link
Member

eric-wieser commented Nov 16, 2021

Prerequisites

  • Put an X between the brackets on this line if you have done all of the following:
    • Checked that your issue isn't already filed.
    • Reduced the issue to a self-contained, reproducible test case.

Description

calc, the tactic, is confused by a local variable called eq.

Steps to Reproduce

example (eq : ℕ) : 1 = 1 :=
begin
  calc 1 = 1 : rfl
     ... = 1 : rfl,
end

Expected behavior: No diagnostics

Actual behavior: invalid occurrence of field notation

Reproduces how often: Always

Versions

Lean (version 3.35.1, commit 4887d8a, Release)

@eric-wieser
Copy link
Member Author

I think this is the start of the offending code:

auto& data = m_p.new_ast("exact_shortcut", pos, m_p.get_token_info().value());
ast_id arg_ast; expr arg;
std::tie(arg_ast, arg) = parse_qexpr();
id = data.push(arg_ast).m_id;
r = m_p.mk_app(m_p.save_pos(mk_constant(get_interactive_tactic_full_name(m_tac_class, "refine")), pos), arg, pos);
if (m_use_istep) r = mk_tactic_istep(m_p, r, pos, pos, id, m_tac_class);

@digama0
Copy link
Member

digama0 commented Nov 17, 2021

I believe the issue is in the quoting and antiquoting that occurs when translating the calc proof to a pexpr to pass to refine. The calc part elaborates to the equivalent of:

example (eq : ℕ) : 11 :=
by tactic.interactive.refine ``(@eq.trans _ 1 1 1 rfl rfl)

which fails because you can't write @eq.trans when eq is a local variable (which seems like an issue all on its own, but probably for another day). Using calc directly doesn't have this issue because it directly generates an expr.const `eq.trans which can't be misinterpreted.

@digama0
Copy link
Member

digama0 commented Nov 17, 2021

This is also visible as a difference in how expr vs pexpr quoting is handled:

example (eq : ℕ) : 1 = 1 :=
by exact %%`(@eq.trans _ 1 1 1 rfl rfl) -- ok, uses global eq.trans

example (eq : ℕ) : 1 = 1 :=
by exact %%``(@eq.trans _ 1 1 1 rfl rfl) -- fail, tries to project on the local variable

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 a pull request may close this issue.

2 participants