aboutsummaryrefslogtreecommitdiff
path: root/lib
diff options
context:
space:
mode:
authorLukasz Kasprzak <lukas@labunix.xyz>2026-08-12 17:02:48 +0200
committerLukasz Kasprzak <lukas@labunix.xyz>2026-08-12 17:02:48 +0200
commite5b368dec8fdc9ab983ee0f1dee69c37883cbe12 (patch)
tree39360eccd3fa8ee5379fc46276d1e0ef0e6ff2b5 /lib
parent5d5454208464892e96310efd99ec9db09171f982 (diff)
downloadcolitur-e5b368dec8fdc9ab983ee0f1dee69c37883cbe12.tar.gz
colitur-e5b368dec8fdc9ab983ee0f1dee69c37883cbe12.zip
docs: three comments that outlived the rules they described
All three are the project's own "correct code, wrong explanation" shape, found by the final review of the RG 113 work. No behaviour change. test_rite_ef.ml's registered Alcotest label said "Thomas of Villanova observed, Maurice commemorated" while the test asserts the Ember Wednesday is observed, Thomas is the sole commemoration and Maurice is omitted -- the opposite of two of its three assertions. The body's own doc comment was right; only the name a test run prints was wrong. validate.ml's lead-in still said origin is reconstructed as Sanctoral uniformly because the EF admit "reads only rank and slug, never origin". That stopped being true in ea22ad2: admit now orders by band, and band reads origin via is_temporal, so a temporal-origin commemoration relabelled Sanctoral would be scored on the wrong table entry. The code below already recovers the origin exactly; only this comment lagged. precedence_ef.ml's band guard justified itself by citing celebration.mli as saying a demoted feast retains its rank for RG 111's admission-COUNT purposes. celebration.mli says the opposite -- it names the ORDERING use the guard removes. The guard is right for a reason it did not give: rank stays load-bearing through RG 111(b)'s "de festo II classis" floor, which is what excludes these entries from a II-class Sunday's slot. Both the citation and celebration.mli's own now-stale line are corrected, each recording what it previously claimed.
Diffstat (limited to 'lib')
-rw-r--r--lib/kernel/celebration.mli13
-rw-r--r--lib/kernel/validate.ml18
-rw-r--r--lib/rites/rite_ef/precedence_ef.ml17
3 files changed, 33 insertions, 15 deletions
diff --git a/lib/kernel/celebration.mli b/lib/kernel/celebration.mli
index a3c2960..85f7af4 100644
--- a/lib/kernel/celebration.mli
+++ b/lib/kernel/celebration.mli
@@ -1,7 +1,14 @@
(** Whether this celebration can be the observed day at all. The 1960 reform
- reduced many feasts to a bare commemoration; they retain a rank (RG 111
- orders admitted commemorations by dignity) but can never be observed. NOT
- a fifth rank: RG 8 fixes the classes at four. *)
+ reduced many feasts to a bare commemoration; they retain a rank but can
+ never be observed. NOT a fifth rank: RG 8 fixes the classes at four.
+
+ What the retained rank is FOR (corrected 2026-08-12): this line formerly
+ read "RG 111 orders admitted commemorations by dignity". Ordering is no
+ longer done by rank at all -- it moved to the rite's own table of
+ precedence (RG 113) in commit ea22ad2, and a bare commemoration has no
+ row in that table. The rank remains load-bearing for ADMISSION: RG 111(b)
+ reserves a II-class Sunday's single slot "de festo II classis", a floor
+ read off this rank directly. *)
type status = Feast | Commemoration_only [@@deriving sexp]
(** A celebration. Parameterised by the rite's rank type only. *)
diff --git a/lib/kernel/validate.ml b/lib/kernel/validate.ml
index 24adcd8..ffeb89e 100644
--- a/lib/kernel/validate.ml
+++ b/lib/kernel/validate.ml
@@ -293,13 +293,17 @@ let run (rite : ('s, 'r) Rite.t) (layer : 'r Layer.t) ~year =
"transfer placement did not reach a fixed point within the round guard (RG 96-98)";
(* "admission": re-offer this day's own admitted commemorations
back to [rite.rules.admit] and require the exact same set back.
- [origin] is reconstructed as [Sanctoral] uniformly:
- {!Liturgical_day.t} does not retain a commemoration's original
- origin, and the real EF [admit] (precedence_ef.ml) reads only
- rank and slug from a candidate, never [origin], so this
- reconstruction is exact for it; documented in validate.mli as
- the one place a rite whose [admit] DOES consult [origin] could
- see a false negative from this check. *)
+ [origin] is RECOVERED, not fabricated -- see the fuller note
+ below on [as_candidates]. It was formerly reconstructed as
+ [Sanctoral] uniformly, justified by the claim that the real EF
+ [admit] reads only rank and slug and never [origin]. That claim
+ is now FALSE: since ea22ad2 the EF [admit] orders by [band]
+ (RG 113), and [band] does read [origin] via [is_temporal], so a
+ temporal-origin commemoration relabelled [Sanctoral] would be
+ scored on the wrong table entry. The recovery below is exact,
+ not a heuristic: [resolve] builds exactly one temporal
+ candidate per day, so a slug match against the day's own
+ temporal office identifies it unambiguously. *)
let observed_candidate : 'r Precedence.candidate =
{ Precedence.cel = d.Liturgical_day.observed; origin = Precedence.Sanctoral }
in
diff --git a/lib/rites/rite_ef/precedence_ef.ml b/lib/rites/rite_ef/precedence_ef.ml
index 8452e69..750da8b 100644
--- a/lib/rites/rite_ef/precedence_ef.ml
+++ b/lib/rites/rite_ef/precedence_ef.ml
@@ -157,11 +157,18 @@ let band (ctx : Vocab_ef.season Precedence.context) (c : Vocab_ef.rank Precedenc
(e.g. sancti:09-22o:4:r for Maurice, rank 4, against Thomas's own
sancti:09-22:3:w, rank 3, on the day Thomas is observed -- test_oracle
.ml's own [test_identity_rank_corroboration]). Restricted to [status];
- [rank] itself is untouched, since {!Celebration.status}'s own doc
- comment is explicit that a demoted feast "retains a rank" for RG 111's
- admission-COUNT purposes (I/II/III/IV class thresholds), which this
- guard does not touch -- only ORDERING among candidates already offered
- to {!admit} changes. *)
+ [rank] itself is untouched, and stays load-bearing for a demoted feast:
+ RG 111(b)'s "scilicet de festo II classis" floor ({!admit} below) reads
+ [rank] directly, and it is exactly that floor which excludes these
+ Class3 entries from a II-class Sunday's single slot. Only ORDERING among
+ candidates already offered to {!admit} changes here.
+ NOTE, corrected: this comment previously cited {!Celebration.status}'s
+ own doc comment as saying a demoted feast retains its rank for RG 111's
+ admission-COUNT purposes. That misquotes it -- celebration.mli says RG
+ 111 "orders admitted commemorations by dignity", i.e. it names the
+ ORDERING use this guard removes, not a counting one. celebration.mli's
+ line is itself now stale: ordering moved from dignity to [band] in
+ ea22ad2. The guard is right; its former justification was not. *)
if status = Celebration.Commemoration_only then unclassified
(* 1: Nativity, Easter Sunday, Pentecost Sunday (I class w/ octave). *)
else if is_temporal && rank = Class1 && ((m = 12 && d = 25) || off = 0 || off = 49) then 1