From 6d6ba502d8022d9e0b8cdc5302f5761d39895192 Mon Sep 17 00:00:00 2001 From: Lukasz Kasprzak Date: Wed, 12 Aug 2026 10:40:27 +0200 Subject: kernel+rite-ef: correct stale plan-relative deferrals (item 7, part 2) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Several comments described work as "arriving with Plan 3" or "waiting for Plan 3" that either shipped without it or refer to the wrong future plan number, all now false in ways that would mislead the next reader: - temporal_ef.ml (two places) and precedence_ef.ml said the Major Litanies (25 April, RG 80) "arrive with Plan 3's sanctoral". Plan 3 shipped, in this branch, without them; register §6 tracks this as a plain open item with no plan committed to build it, and now says so. - temporal_ef.ml said the Sacred Triduum's "own named offices are a Plan 3 sanctoral addition". Wrong on two counts: Plan 3 shipped without adding them, AND a proper office for I-class FERIAS was never a sanctoral matter in the first place (RG 21 defines "feria" to exclude Sundays/feasts, not the reverse). 2026-04-02/03/04 still resolve to the ordinary Passiontide ferial fallback's own generic slugs (ef-passiontide-2-{thursday,friday,saturday}), confirmed against real output; register §6 now records this as its own open item. - temporal_ef.ml said the Rogation-Wednesday commemoration (Ascension Vigil day, entry 21) "waits for RG 108-111" -- both the precedence framework and RG 108-111 exist now; the Wednesday's own commemoration is still never constructed, but for a different, still-real reason (no candidate is wired for it), not a forward dependency. Fixed at both of this comment's two occurrences in the file. - vocab.ml/vocab.mli's `seasons` field doc said "Validate's contiguity check reads this" -- false since validate.ml's "seasons" check switched to Rite.t.season_runs in this branch (rite-supplied, to support a season appearing in more than one run, which the modern form's Ordinary Time needs and EF does not). - vocab.ml/vocab.mli's `ranks` field doc said "it is not a precedence relation until Plan 3 defines one" -- Plan 3 did define one (RG 111's dignity ordering), but as its own small, separately-hardcoded function in precedence_ef.ml, not one derived from this field; corrected to say so precisely rather than leaving a forward-looking claim unresolved. - The lectionary bootstrap (reading citations, Liturgical_day.t's own `citations` field) is called "Plan 3" at slug.ml, vocab_ef.ml, and three places in temporal_ef.ml, but "Plan 4" at liturgical_day.mli (whose own doc comment -- "always empty until Plan 4" -- is the authoritative one: the SANCTORAL bootstrap is Plan 3 and shipped; the LECTIONARY bootstrap is a separate, later Plan 4). All six corrected to say Plan 4, cross-referencing the Plan 3/4 distinction at the first (slug.ml) occurrence so the reasoning is not duplicated six times. No behaviour change: every edit here is a comment/documentation correction. Verified byte-identical `colitur day` output across 1583, 1900, 1902, 2008, 2011, 2026, 2038, 9999. 259/259 tests green. --- lib/kernel/vocab.ml | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) (limited to 'lib/kernel/vocab.ml') diff --git a/lib/kernel/vocab.ml b/lib/kernel/vocab.ml index 78729bb..bcb48b8 100644 --- a/lib/kernel/vocab.ml +++ b/lib/kernel/vocab.ml @@ -7,13 +7,32 @@ parametric types natively. *) type ('s, 'r) t = { seasons : 's list; - (** canonical liturgical-year order; Validate's contiguity check reads this *) + (** canonical liturgical-year order. CORRECTED (final fix wave, item + 7): this used to say "Validate's contiguity check reads this" -- + false since validate.ml's own "seasons" check switched to + {!Colitur_kernel.Rite.t}.season_runs in this branch (Plan 2 + carried item 1: EF has each season in one run, but the modern + form's Ordinary Time does not, so the expected run sequence had + to become rite-supplied rather than derived from this field). + For EF specifically {!Rite_ef.rite_ef.ml} sets season_runs to + this very list, so the two happen to agree there, but Validate + itself no longer reads [seasons] to build its expectation. *) season_to_string : 's -> string; season_of_string : string -> 's option; ranks : 'r list; (** documentation order, highest first. Plan 2 uses it only for the - closure check -- it is not a precedence relation until Plan 3 - defines one. *) + closure check. CORRECTED (final fix wave, item 7): this used to + say "it is not a precedence relation until Plan 3 defines one" -- + Plan 3 did define one (RG 111's dignity ordering, Rite_ef. + Precedence_ef.dignity/compare_dignity), but as its OWN small, + separately-hardcoded function, not one derived from this field: + [admit] needs Vocab_ef.rank's dignity as plain data (RG 8's four + classes), and reusing this field's own [int list] position would + couple that meaning to documentation order the way {!band} is + explicitly NOT allowed to (precedence_ef.ml's own file comment). + This field therefore still carries no precedence relation of its + own; a rite that wanted one derived from it would have to build + it itself. *) rank_to_string : 'r -> string; rank_of_string : string -> 'r option; } -- cgit v1.3 From d0b78ca2ef533080d4621b22071718bb8d3a6158 Mon Sep 17 00:00:00 2001 From: Lukasz Kasprzak Date: Wed, 12 Aug 2026 11:19:51 +0200 Subject: 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. --- README.md | 3 ++- lib/kernel/precedence.mli | 12 +++++++----- lib/kernel/vocab.ml | 2 +- lib/kernel/vocab.mli | 2 +- lib/rites/rite_ef/precedence_ef.ml | 10 +++++----- lib/rites/rite_ef/precedence_ef.mli | 2 +- 6 files changed, 17 insertions(+), 14 deletions(-) (limited to 'lib/kernel/vocab.ml') diff --git a/README.md b/README.md index 9b11d73..6f71f6c 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,8 @@ reading citations, correct to year 9999. See the design and rules research under opam switch create . 5.2.0 -y # first time: local OCaml switch opam install -y dune alcotest qcheck qcheck-alcotest sexplib ppx_sexp_conv dune build -dune test +dune test # fast suite (~3s) +COLITUR_EXHAUSTIVE_SWEEP=1 dune test --force # + every year 1583-9999 (~50s) dune exec colitur -- easter 2026 # Easter and its Easter-relative anchors dune exec colitur -- temporal 2026 # the EF temporal cycle only, one line per day dune exec colitur -- day 2026 # the full resolved EF calendar (temporal + sanctoral) diff --git a/lib/kernel/precedence.mli b/lib/kernel/precedence.mli index 4225eb7..ae054dd 100644 --- a/lib/kernel/precedence.mli +++ b/lib/kernel/precedence.mli @@ -47,11 +47,13 @@ type ('s, 'r) rules = { {!resolve}'s own [omitted] accounting distinguishes an admitted candidate from a dropped one by PHYSICAL equality ([==]) on the candidate value, not structural equality -- a rebuilt record is - [=] to the original but not [==], so {!resolve} would then count - it as dropped a SECOND time (once because it is genuinely absent - from the admitted set, once because its identity no longer - matches its own admitted copy), silently double-counting rather - than raising. This obligation previously lived only in one rite's + [=] to the original but not [==], so {!resolve} cannot match the + rebuilt copy against the original it was given. The celebration + then surfaces TWICE in the same day's result -- once in + {!resolution.commemorations} (the rebuilt copy, admitted) and once + in {!resolution.omitted} (the original, which nothing in the + admitted set matches). One admission, double-reported, silently + rather than raising. This obligation previously lived only in one rite's own module documentation (Rite_ef.Precedence_ef.admit); stated here because this signature -- not any one rite's implementation of it -- is what an author of the next rite reads. *) diff --git a/lib/kernel/vocab.ml b/lib/kernel/vocab.ml index bcb48b8..a4e61a3 100644 --- a/lib/kernel/vocab.ml +++ b/lib/kernel/vocab.ml @@ -14,7 +14,7 @@ type ('s, 'r) t = { carried item 1: EF has each season in one run, but the modern form's Ordinary Time does not, so the expected run sequence had to become rite-supplied rather than derived from this field). - For EF specifically {!Rite_ef.rite_ef.ml} sets season_runs to + For EF specifically [Rite_ef.rite] sets season_runs to this very list, so the two happen to agree there, but Validate itself no longer reads [seasons] to build its expectation. *) season_to_string : 's -> string; diff --git a/lib/kernel/vocab.mli b/lib/kernel/vocab.mli index bcb48b8..a4e61a3 100644 --- a/lib/kernel/vocab.mli +++ b/lib/kernel/vocab.mli @@ -14,7 +14,7 @@ type ('s, 'r) t = { carried item 1: EF has each season in one run, but the modern form's Ordinary Time does not, so the expected run sequence had to become rite-supplied rather than derived from this field). - For EF specifically {!Rite_ef.rite_ef.ml} sets season_runs to + For EF specifically [Rite_ef.rite] sets season_runs to this very list, so the two happen to agree there, but Validate itself no longer reads [seasons] to build its expectation. *) season_to_string : 's -> string; 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 : -- cgit v1.3