RFD-0019 — Patterns are first-class parameterized templates

Question

Ontology authors repeatedly model similar shapes — correlative pairs (rights / duties), part-whole relationships, role-mediating relations. Should the language admit lightweight reuse for these shapes that’s lighter than functor modules (RFD-0009)?

Decision

Patterns are first-class language items: parameterized templates that emit declarations when instantiated. Pattern declaration shape:

pattern <name>(<TypeArgs>) {
    <declarations that reference TypeArgs>
}

Instantiation:

use pattern <name><TypeArgs> as <instance_name>

Patterns can also surface via bespoke per-pattern syntax for common shapes (e.g., correlative_pair(...), part_whole(...)).

Patterns are not generic concepts (RFD-0009 still applies). A pattern instantiation produces a fresh set of concept / relation / property declarations bound to the type arguments — flat declarations, no parametric type machinery in the resulting concepts.

Rationale

Patterns hit the middle ground. Functor modules abstract over whole module shapes; one-off concepts handle one-off cases. Patterns capture the recurring 3-to-10-declaration shape that doesn’t justify a full module split but does deserve a name and reuse mechanism.

Bespoke syntax for popular shapes. Some patterns are common enough that a reader benefits from immediate recognition. correlative_pair(Right, Duty) reads as “the Right/Duty correlative pair” instantly; use pattern correlative<Right, Duty> as ... reads less directly. The bespoke surface is sugar that lowers to the same pattern instantiation.

Patterns emit, they don’t parameterize. A pattern instance produces concrete declarations that the compiler treats as if the author had hand-written them. There’s no runtime cost to pattern instantiation, no parametric concept tracking, no constraint-propagation across instances.

Consequences

• pattern is a reserved item kind with its own AST node.
• Pattern bodies admit any declaration form (concepts, relations, properties, rules, computes, etc.).
• Pattern instances expand at elaboration time; downstream phases see the expanded declarations.
• Bespoke per-pattern surface forms (correlative_pair, part_whole) are language-recognized sugar; the compiler ships with a small set, and packages may declare their own.