Skip to content
This repository has been archived by the owner on Oct 14, 2023. It is now read-only.

Tactic mode "escapes" sections for sections within namespaces #1773

Open
1 task done
bmsherman opened this issue Jul 28, 2017 · 1 comment
Open
1 task done

Tactic mode "escapes" sections for sections within namespaces #1773

bmsherman opened this issue Jul 28, 2017 · 1 comment
Labels

Comments

@bmsherman
Copy link

bmsherman commented Jul 28, 2017

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

Consider the following code:

namespace foo
section
parameter x : ℕ

def my_x : ℕ := x

lemma bar : my_x = my_x + 0
  := nat.add_zero my_x

lemma bar' : my_x = my_x + 0
:= begin apply (nat.add_zero my_x) end --error on this line

end
end foo

Actual behavior: Definition of bar' fails with the error

type mismatch at application
  nat.add_zero my_x
term
  my_x
has type
  ℕ → ℕ
but is expected to have type
  ℕ
state:
x : ℕ
⊢ my_x = my_x + 0

What is happening is that inside the tactic mode, the environment is behaving as if it were outside the section, and thus my_x takes an argument corresponding to the parameter x. If one removes the lines namespace foo and end foo, so that the section is no longer within a namespace, then the definition of bar' works.

Expected behavior: The environment should behave similarly in tactic mode as outside of tactic mode. That is, it should behave as it does behave for sections that are not within namespaces.

Versions

Lean HEAD from July 21, 2017, Lean (version 3.2.1, commit 667e1e1, Release)

@bmsherman bmsherman changed the title Tactic mode "escapes sections" for sections within namespaces Tactic mode "escapes" sections for sections within namespaces Jul 28, 2017
@gebner
Copy link
Member

gebner commented Jul 28, 2017

The problem is that the my_x alias for my_x x is stored in the parser right now. A fix for this will probably have to wait until we implement #1674.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants