Minutes April 05 2023 - math-comp/math-comp GitHub Wiki
Participants: Julien, Pierre, Reynald, Thomas, Yves
https://github.com/math-comp/math-comp/pull/934 (renaming long suffixes)
conclude about- the
i
inltriX2l
means "interior" - the
e
inltreXn2l
means "exterior" - TODO: put underscores in front of
i
ande
- rule: don't put
_
when the suffix starts with a cap - the documentation mentions
sp
/sn
but they are not used that much (exception:ltr_spaddl
, etc.)- TODO: update the documentation?
- TODO: modify the contributing guidelines
maxrnMr
->maxr_nMr
- what about
div
->MV
?- makes for difficult to read names (
MVlM
) - search for
M
would also displayMV
- just add
- "V"
to the search
- just add
- by the way, we have
B
instead ofND
because ofnat
- let us keep
div
- makes for difficult to read names (
ler_pdivl_mulr
->ler_pdivl_Mr
orler_pdivlMr
?- the 2nd
_
would mean "equal" - however, we do not want to change
ler_subl_addl
->lerBlDl
- rule: put
_
in front of small prefixes but not suffixes
- the 2nd
https://github.com/math-comp/math-comp/pull/790 ?
merge- NB:
name
->binder
- TODO(rei): merge
https://github.com/math-comp/math-comp/pull/980 )
drop support for 8.13 and 8.14? (c.f.- notation that does not work with 8.13 et 8.14
- drop to support
0%O
and1%O
(even though they are temporary) - we can drop because we sill support three versions
- where is the statement that we support three versions?
- no need to be clear about that
reminder about the poll for the doc spring sprint:
https://evento.renater.fr/survey/mathcomp-2-documentation-sprint-ck97yi5r
- TODO: advertise again the sprint
- we took a quick look at the tentative doc for
eqtype
: - question: how to document notations such as
[eqType of _]
?- because they are going to look alike across many files
and there may be many of them in
ssralg
andorder
- because they are going to look alike across many files
and there may be many of them in
- we may need to add the topic of documenting HB to the program of the sprint
[the A of B]
is to recover an instance- Remark(enrico): may become less and less used, since Coq 8.16 if you write
nat
where aneqType
is expected, the elaborator will generatenat_eqType
for you, no need to wrapnat
into[the eqType of ...]
- (the elaborator uses the solution to the unification problem triggered by the fancy notation with Phantom arguments, in some sense it triggers the same unification). These are the "reverse coercions" thing.
- Remark(enrico): may become less and less used, since Coq 8.16 if you write
clone
reconstructs a canonical instance using a constructor e.g.Equality.clone nat
isEquality.Pack nat nat_eqClass
,Equality.clone T
will eta-expand and hence clone should be used with caution.[eqType of _]
are string notations for clone (historically it was not always eta-expanding, bug only in some very specific cases)copy
copies the class but might change the key, e.g.Equality.copy T nat
is anEquality
class onT
which is definitely equal to that ofnat
.S.on T
is an abbreviation ofS.copy T T
, i.e. it tries to infer a class instance ofS
onT
(either because it already exists onT
or because it can be obtained by unfolding) a typical usecase is for aliases. Example, if I create an aliasnat' := nat
and want to copy everything up toChoice
I can doHB.instance Definition _ := Choice.on nat'
and then I can create diverging instances from nat.- NB: don't document if it is not supposed to last (e.g.,
.on
)
- TODO: pierre and reynald to meet next week to make progress