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

RFC: optionally disable automatic namespace #6436

Closed
madvorak opened this issue Dec 23, 2024 · 3 comments
Closed

RFC: optionally disable automatic namespace #6436

madvorak opened this issue Dec 23, 2024 · 3 comments
Labels
RFC Request for comments

Comments

@madvorak
Copy link
Contributor

madvorak commented Dec 23, 2024

I would like to have a project-wide setting to disable automatic opening of a namespace for the declaration's name prefix.
I would like everything inside a declaration to be evaluated the same way as if it was example instead.

theorem List.map_comp_comp {α β γ δ : Type}
    (l : List α) (f : α → β) (g : β → γ) (h : γ → δ) :
    l.map (h ∘ g ∘ f) = ((l.map f).map g).map h := by
  -- I want `map (g ∘ f) l` to be a syntax error
  have fg : map (g ∘ f) l = (l.map f).map g := by simp
  rw [←fg]
  simp

In the example above, with the new settings, I would be forced to write List.map (g ∘ f) l or l.map (g ∘ f) because map (g ∘ f) l would cause a syntax error. Currently map (g ∘ f) l is allowed and I don't like it.

Discussion:
https://leanprover.zulipchat.com/#narrow/channel/270676-lean4/topic/Disable.20automatic.20namespace

@madvorak madvorak added the RFC Request for comments label Dec 23, 2024
@Command-Master
Copy link
Contributor

Do you want to be able to use map_comp_comp without a namespace here, or even it only with the namespace?

@madvorak
Copy link
Contributor Author

madvorak commented Jan 2, 2025

I want map_comp_comp to be error as well.

@Kha
Copy link
Member

Kha commented Jan 10, 2025

Please follow the RFC template if you want your RFC to be reviewed. I shouldn't have to mention that "I don't like it" is not sufficient motivation. However, I can also safely say that we would be likely to close even a comprehensive RFC for this proposal as changing such fundamental properties of the language's semantics needs to pass an extremely high justification barrier.

@Kha Kha closed this as not planned Won't fix, can't repro, duplicate, stale Jan 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request for comments
Projects
None yet
Development

No branches or pull requests

3 participants