summaryrefslogtreecommitdiff
path: root/lib/rites/rite_ef
diff options
context:
space:
mode:
authorLukasz Kasprzak <lukas@labunix.xyz>2026-08-12 11:19:51 +0200
committerLukasz Kasprzak <lukas@labunix.xyz>2026-08-12 11:19:51 +0200
commitd0b78ca2ef533080d4621b22071718bb8d3a6158 (patch)
tree561eafb167b27f0ba6eb9c03012359a6d8b56129 /lib/rites/rite_ef
parent6d6ba502d8022d9e0b8cdc5302f5761d39895192 (diff)
downloadcolitur-d0b78ca2ef533080d4621b22071718bb8d3a6158.tar.gz
colitur-d0b78ca2ef533080d4621b22071718bb8d3a6158.zip
docs: close the final review's four documentation residues
precedence_ef.mli said "there is no fifth, unclassified case" after the same commit renumbered the disposition list from four cases to five; the count is now six. precedence.mli's physical-equality obligation described the failure mode as counting a drop "a SECOND time (once because it is genuinely absent, once because its identity no longer matches)" -- the same condition stated twice. What actually happens to a rebuilt candidate record is that the celebration surfaces in BOTH commemorations (the copy) and omitted (the original), one admission double-reported. precedence_ef.ml carried the same muddled sentence, which is where the kernel's copy came from; both now say it plainly. vocab.ml/.mli referenced {!Rite_ef.rite_ef.ml} -- a filename inside an odoc reference, which is malformed. Now plain [Rite_ef.rite]. README documented only `dune test`, so the exhaustive 1583-9999 Validate sweep was discoverable only by reading test_validate.ml's own comment. With no CI in this repo, that line is what stands between a committed artifact and one anyone runs. No behaviour change: `colitur day` output is byte-identical across 1583, 1900, 1902, 2008, 2011, 2026, 2038 and 9999 (2921 days, both domain edges). 259 tests by default, 260 with the sweep.
Diffstat (limited to 'lib/rites/rite_ef')
-rw-r--r--lib/rites/rite_ef/precedence_ef.ml10
-rw-r--r--lib/rites/rite_ef/precedence_ef.mli2
2 files changed, 6 insertions, 6 deletions
diff --git a/lib/rites/rite_ef/precedence_ef.ml b/lib/rites/rite_ef/precedence_ef.ml
index fcd2116..db7e708 100644
--- a/lib/rites/rite_ef/precedence_ef.ml
+++ b/lib/rites/rite_ef/precedence_ef.ml
@@ -685,11 +685,11 @@ let admit ~(observed : Vocab_ef.rank Precedence.candidate)
than rebuilt ones; undocumented for rite authors" -- documented here,
now that this is the function that note was about). Building a fresh
[{ c with ... }] record anywhere below would silently defeat that
- accounting: the dropped candidate would then match nothing in
- [admitted], and {!Precedence.resolve} would count it as dropped a
- SECOND time (once for real, once because its identity no longer
- matches its own admitted copy) without ever raising -- a silent
- double-count, not a crash, which is exactly why this comment exists. *)
+ accounting: the original would then match nothing in [admitted], so the
+ celebration would surface TWICE in the same day -- once in
+ [commemorations] (the rebuilt copy) and once in [omitted] (the original,
+ which nothing admitted matches). One admission, double-reported, and no
+ crash to announce it, which is exactly why this comment exists. *)
let sorted = List.stable_sort compare_dignity comms in
let is_privileged (_, p) = p = Precedence.Privileged in
let observed_rank = observed.Precedence.cel.Celebration.rank in
diff --git a/lib/rites/rite_ef/precedence_ef.mli b/lib/rites/rite_ef/precedence_ef.mli
index 161d890..55f947e 100644
--- a/lib/rites/rite_ef/precedence_ef.mli
+++ b/lib/rites/rite_ef/precedence_ef.mli
@@ -135,7 +135,7 @@ val sunday_marker : string
can construct: [Vocab_ef.rank] (RG 8) and {!Celebration.status} are both
closed variants, and the five cases above -- an if/else-if chain ending
in the unconditional [Commemorate] catch-all -- exhaust every value
- those two fields can take between them; there is no fifth,
+ those two fields can take between them; there is no sixth,
"unclassified" case the way {!band} needs one, because this function's
own return type has no such slot to fall into by accident. *)
val disposition :