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: Enhancing the extended field notation (dot notation) #5482

Open
FR-vdash-bot opened this issue Sep 26, 2024 · 1 comment · May be fixed by #6267
Open

RFC: Enhancing the extended field notation (dot notation) #5482

FR-vdash-bot opened this issue Sep 26, 2024 · 1 comment · May be fixed by #6267
Labels
P-medium We may work on this issue if we find the time RFC Request for comments

Comments

@FR-vdash-bot
Copy link
Contributor

FR-vdash-bot commented Sep 26, 2024

Proposal

There have been several RFCs about the enhancement of dot notation. (#1629, #3031) This RFC suggests using attributes to specify the namespace of the function used by dot notation, and using self (suggested in #1629) to specify arguments. (Note: If the function is a field of a type class, the self name will not work because the typeclass parameter takes up that name. This method might need to be improved.) For example:

class A (α : Type _) where
  a : α → Nat

structure B where
  b : Nat

instance : A B := ⟨B.b⟩

attribute [dot_namespace A] B

def A.get {α : Type _} [A α] (self : α) : Nat := a self

variable (b : B)

#check b.get -- Wanted `A.get b`, still pretty print as `b.get`

This helps a lot with the use of typeclass APIs in Mathlib. For example, it makes it easier to use APIs in the FunLike and SetLike hierarchies, and easier to migrate from specialized APIs to general APIs based on type classes.

The approach proposed in this RFC is closer to current mechanisms than previous RFCs, thus it is easier to implement and maintain and less likely to produce unintended results.

Community Feedback

Previous RFCs and related discussions: #1629 #3031 Zulip Zulip Zulip Zulip

Impact

Add 👍 to issues you consider important. If others benefit from the changes in this proposal being added, please ask them to add 👍 to it.

@FR-vdash-bot FR-vdash-bot added the RFC Request for comments label Sep 26, 2024
@leanprover-bot leanprover-bot added the P-medium We may work on this issue if we find the time label Sep 27, 2024
kmill added a commit to kmill/lean4 that referenced this issue Nov 30, 2024
This PR introduces the `dotParam` marker to indicate which parameter should be used for generalized field notation ("dot notation"). Example:
```
class A (α : Type _) where
  a : α → Nat

def A.get {α : Type _} [A α] (self : dotParam α) : Nat := a self

structure B where
  b : Nat

instance : A B := ⟨B.b⟩

namespace B
export A (get)
end B

#check fun (b : B) => b.get
-- b.get : Nat
```
The pretty printing code is modified to support the `export`-resolved dot notation introduced in leanprover#6189.

Closes leanprover#1629, closes leanprover#5482
@kmill kmill linked a pull request Nov 30, 2024 that will close this issue
@kmill
Copy link
Collaborator

kmill commented Nov 30, 2024

#6267 implements a version of this RFC, paired with the already merged #6189, but the effect is not exactly the same. It has a mechanism where you use export paired with a dotParam-annotated argument. A limitation of is that you don't get to use everything from another namespace, only the names that you export.

Potentially we could also add a mechanism like what's proposed in this issue — a way to export entire namespaces for dot notation purposes — but I'd appreciate feedback with motivating examples.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P-medium We may work on this issue if we find the time RFC Request for comments
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants