blob: e54a0b1b8e7a1ee4bd25b954900b35dc6e6db40a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
open Colitur_kernel
(** The EF lectionary resolution chain. All rubric knowledge about what a day
with no proper falls back to lives here, not in the kernel.
[lectionary] is caller-supplied, not loaded by this module -- the same
reasoning rite_ef.mli's own [context] doc comment already gives for why
the sanctoral {!Colitur_kernel.Layer.t} stays a separate argument rather
than an embedded field: it lets a caller load data/ef/lectionary.sexp
however suits it, and leaves room for a future diocesan/proper
lectionary overlay to attach without this module changing at all.
An eager filesystem read at module initialisation was tried first and
reverted (fix round 1, coordinator review): [readings] used to close
over a [lectionary] value loaded as a side effect of this module being
LINKED, so `colitur easter <year>` -- which touches no lectionary data
at all -- died at startup the moment data/ef/lectionary.sexp was
missing from a bare `dune build`'s own default target (it was only
present because test/dune's own deps happened to materialise it,
masking the gap in every test run). See the task report for the
reproduction.
Steps 1-3 (Tasks 4-5): the observed celebration's own proper, else the
day's own temporal slug in the lectionary, else -- for a weekday whose
own slug has no entry -- the preceding Sunday's temporal slug (never its
observed one; a Sunday is guarded out because it has no PRECEDING Sunday
to resume, not because consulting itself would loop -- [readings] is not
recursive, see its own implementation comment). A day matching none of
the three gets [] for now -- the Commons (Task 6) are not built here. *)
val readings :
lectionary:Lectionary.t ->
observed:Vocab_ef.rank Celebration.t ->
temporal:(Vocab_ef.season, Vocab_ef.rank) Temporal.t ->
date:Date.t ->
temporal_at:(Date.t -> (Vocab_ef.season, Vocab_ef.rank) Temporal.t) ->
Citation.t list
|
