Skip to content

Commit

Permalink
feat(templates/glossary): explain dot notation
Browse files Browse the repository at this point in the history
As mentioned in #226.
  • Loading branch information
Vierkantor authored Nov 22, 2021
1 parent 4fdd0f7 commit 2901419
Showing 1 changed file with 6 additions and 0 deletions.
6 changes: 6 additions & 0 deletions templates/glossary.md
Original file line number Diff line number Diff line change
Expand Up @@ -149,6 +149,12 @@ Diamonds which cross library boundaries -- such as ones in which part of the typ

* [Forgetful Inheritance](https://leanprover-community.github.io/mathlib_docs/notes.html#forgetful%20inheritance), also from the mathlib documentation, for a discussion on a general pattern for avoiding diamonds in the case of "richer" and poorer structures on a type

### dot notation / generalized field notation / generalized projections

The syntax sugar allowing notations such as `((foo a b c).bar x.y).baz`.

Lean provides two interpretations of the syntax `foo.bar`: it can mean the declaration `bar` in the `foo` namespace, or it can be generalized field notation. Suppose `foo` has type `C x1 ... xn`, with `C` some constant and `x1 ... xn` arbitrary, then `foo.bar` is sugar for `C.bar foo`. For calls of the form `foo.bar _ ... _` with (implicit or explicit) arguments, Lean is smart enough to expand to `C.bar _ ... foo _ ... _`, so that everything typechecks. In these previous examples, `foo` can also be a more complicated expression such as function application.

### `equiv`

As distinct from mathematical equality, [`equiv`](mathlib_docs/data/equiv/basic.html) allows for defining an equivalence or congruence of types.
Expand Down

0 comments on commit 2901419

Please sign in to comment.