-
Notifications
You must be signed in to change notification settings - Fork 71
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
Expanding on the naming conventions #793
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to review this PR carefully before it is merged, but that will have to wait at the moment.
Co-authored-by: Fredrik Bakke <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for putting it all together. I do feel like there are some inconsistencies in the description of some of the examples, could you elaborate a bit on the comments?
NAMING-CONVENTIONS.md
Outdated
this happens is in `hom-iso-Group`, which is the construction that returns the | ||
underlying group homomorphism of an isomorphism of group. The fact that a group | ||
isomorphism is an isomorphsim is called `is-iso-iso-Group`, which also uses the | ||
pattern `[type]-[Namespace]`. One could also consider calling it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this [type]-[hypotheses]-[Namespace]
? is-iso
being the type and iso
being the hypothesis. If not, what's the difference between this and the example is-ideal-ideal-Ring
below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Things that go under [type] are the output types of the specification of an entry. In the case of is-iso-hom-Ring
the output type of its specification is UU
. We don't put this in the name. Instead is-iso
is a descriptor of the specification, falling under [name]
in the general pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I follow. What I'm reading is that
is-iso-iso-Group : (f : iso) -> is-iso f
follows[type]-[Namespace]
, butis-ideal-ideal-Ring : (I : ideal) -> is-ideal I
follows[type]-[hypotheses]-[Namespace]
Is that correct?
NAMING-CONVENTIONS.md
Outdated
there is an interchange law for addition over addition, which states that | ||
`(a + b) + (c + d) = (a + c) + (b + d)`. This law is called | ||
`interchange-law-add-add-ℤ`. Again, this naming follows the pattern | ||
`[type]-[Namespace]`, because it states the type of which an element is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again I'd say this is [type]-[name]-[Namespace]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The type of the output of this entry is interchange-law add-ℤ add-ℤ
, so the name here merely describes the type, and the namespace for the integers. In the case is-equiv-succ-ℤ : is-equiv succ-ℤ
this would also fall under [type]-[Namespace]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The explanation on left-unit-law-mul-ℤ
makes this clear now 👌
- We prioritize the readability of the code and avoid subtly different | ||
variations of the same symbol. An important exception is the use of the | ||
[full width equals sign](https://codepoints.net/U+ff1d) for the identity type, | ||
as the standard equals sign is a reserved symbol in Agda. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd also mention the homotopy composition and whiskering situation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other examples are the asterisk vs asterisk operator, and big vee vs small vee. Maybe rephrase to "try to avoid subtly different"
NAMING-CONVENTIONS.md
Outdated
construction of the underlying set of a group returns for each group a set, | ||
which is an element of type `Set`. Similarly, we have `type-Group]`, | ||
`semigroup-Group`, `type-Ring`, `set-Ring`, and so on. Another instance where | ||
this happens is in `hom-iso-Group`, which is the construction that returns the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hom-iso-Group
has the approximate type iso -> hom
, shouldn't it then be [type]-[hypotheses]-[Namespace]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks right
Co-authored-by: Vojtěch Štěpančík <[email protected]>
Co-authored-by: Vojtěch Štěpančík <[email protected]>
Co-authored-by: Fredrik Bakke <[email protected]>
Co-authored-by: Fredrik Bakke <[email protected]>
Co-authored-by: Fredrik Bakke <[email protected]>
name adds no extra useful information. This situation is common in instances | ||
where we omit the `[descriptor]` part of a name. For instance | ||
`is-category-Category` and `is-ideal-ideal-Ring` follow the patterns | ||
`[output-type]-[Namespace]` and `[output-type]-[input-types]-[Namespace]`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second reading I'm not sure why
is-category-Category : (C : Category) -> is-category C
andis-ideal-ideal-Ring : (I : ideal-Ring) -> is-ideal I
are different? Even the modules where they are defined seem to follow the exact same structure.
and not `commutative-×`, and the unit of a modality is called `unit-modality` | ||
and not `unit-○`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although the second example here is also an instance of using a variable in a name, perhaps it still conveys the correct sentiment.
NAMING-CONVENTIONS.md
Outdated
- **[descriptor]:** This part is used to give a custom descriptive name for the | ||
entry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- **[descriptor]:** This part is used to give a custom descriptive name for the | |
entry. | |
- **[descriptor]:** This part is used to give a custom descriptive name for the | |
entry, or refer to the custom descriptive name of another entry. |
If I didn't misunderstand, this is how it is used in the below example is-iso-prop-hom-Ring
.
`[output-type]-[Namespace]`. The construction of the underlying set of a group | ||
returns for each group a set, which is an element of type `Set`. Similarly, we | ||
have `type-Group`, `semigroup-Group`, `type-Ring`, `set-Ring`, and so on. | ||
Another instance where this happens is in `hom-iso-Group`, which is the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't hom-iso-Group
an instance of [output-type]-[input-types]-[Namespace]
?
Another instance where this happens is in `hom-iso-Group`, which is the | ||
construction that returns the underlying group homomorphism of an isomorphism of | ||
group. The fact that a group isomorphism is an isomorphsim is called | ||
`is-iso-iso-Group`, which also uses the pattern `[output-type]-[Namespace]`. One |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this also an instance of [output-type]-[input-types]-[Namespace]
?
`is-iso-iso-Group`, which also uses the pattern `[output-type]-[Namespace]`. One | ||
could also consider calling it `is-iso-hom-iso-Group`, to emphasize that the | ||
underlying group homomorphism of the isomorphism is an isomorphism. However, | ||
this name does not fit our patterns in any way, and the addition of `hom` to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not clear to me how this does not fit our patterns better than the proposed one. Also, the name would be more consistent with is-iso-hom-inv-iso-Group
Co-authored-by: Fredrik Bakke <[email protected]>
| `equiv` | Used for equivalences, and also for names of identity systems of universe-like types | | ||
| `extensionality` | Used for computations of identity types | | ||
| `htpy` | Used for constructions of homotopies, and also for names of identity systems of function-like types | | ||
| `is-property` | Used when `is-prop` is unavailable | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't remember if I already mentioned this, but did you know we actually define is-property
in foundation-core.subtypes
? Although IIRC it is not referred to anywhere.
To give a sense of the kind of general descriptors we use, we list some common | ||
descriptors in the table below. | ||
|
||
| Descriptor | Purpose | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add statement
To give a sense of the kind of general descriptors we use, we list some common | ||
descriptors in the table below. | ||
|
||
| Descriptor | Purpose | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be very good to have an example column for this table as well. That's what I did for the sHoTT project
To give a sense of the kind of general descriptors we use, we list some common | ||
descriptors in the table below. | ||
|
||
| Descriptor | Purpose | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another descriptor pair we use a lot is is
/has
:)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you think of them as descriptors? That seems grammatically very weird.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are modifiers signifying that the type is a property/structure, and then we omit them for the associated total types. It just seems consistent with the scheme.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm willing to come up with our own naming convention, but I'm not willing to come up with a new theory that the verbs to be and to have are modifiers. That idea seems out of this world to me.
| `coh` | Used for proofs of coherence | | ||
| `coherence` | Used to assert coherence | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like the need for coh
is obsoleted by introducing statement
.
No description provided.