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

notation docs #15

Open
jcommelin opened this issue May 15, 2020 · 0 comments
Open

notation docs #15

jcommelin opened this issue May 15, 2020 · 0 comments

Comments

@jcommelin
Copy link
Member

jcommelin commented May 15, 2020

A first start provided by @Vierkantor :
https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/big.20ops/near/195941698

when deciding how to pretty-print an expression,
Lean looks up the notations associated to the head of the expression (e.g. `finset.sum`).
It tries them one by one, until it finds a notation that matches the expression,
then uses that to pretty-print.
The order in which they are tried is the order in which they are stored in the environment structure,
which in this case is the order in which they are defined.
Apparently the priority information is thrown away
(typically it would be highest-priority first, then by order of definition).
This is why the order matters.

A notation definition is associated to the head of the expression it expands to, so
```lean
notation ∑ binders ,  r:(scoped f, finset.sum finset.univ f) := r
```
is associated to the head of the expansion of `r`,
which is the head of `finset.sum finset.univ f`, which is `finset.sum`.
But `finset.univ.sum` doesn't get expanded to `finset.sum finset.univ` at that point,
so you have to write `finset.sum finset.univ` instead of `finset.univ.sum`.
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

No branches or pull requests

1 participant