This is the first overview page for the #p_programming_* namespace. The point is to place
P-programming above any one implementation. The UM runner is one realization. cmpr is another.
The workpad remains the frontier block, while the surrounding namespace accumulates stable definitions.
The current extension is the settling thesis: the semantic result of a step is not raw propagation but a settled state.
#p_programming_workpad
Exploratory frontier. New definitions, objections, candidate laws, and expansion of the envelope.
#p_programming_definitions
Stable claims about what a P-program state is and why the namespace is centered on (E,T,P).
#p_programming_operations
First introduction operators: u + e, u + t, u + p_i.
#p_programming_realizations
Mapping to concrete systems such as #umr_spec and the block/event machinery in cmpr.
#p_programming_settling
Strong semantic claim that a P-program step yields a settled state, not merely a propagated one.
A P-program state is written as u = (E, T, P).
E is the available event structure, T is the current support state,
and P is the available pattern structure.
The broader UM includes f and omega, but the namespace above specific
implementations is most naturally described in terms of what exists, what is active, and what transformations are available.
The name stays with P because persistence, routing, conjunction, transfer, control,
and learned structure are all pattern questions. At the same time, E and T
are essential. A pattern without events has no domain, and a pattern without support has no operational content.
| Operator | Reading |
|---|---|
u + e | Architecture growth: add event or event-space structure. |
u + t | Assignment or activation: assert current support. |
u + p_i | Rule introduction: add an atomic pattern or transfer mechanism. |
These are not the final algebra. They are the first formalized common language across implementations.
| Realization | Status |
|---|---|
#umr_spec |
One concrete realization of P-programming, fixing runner dynamics, threshold creation, and the SN interchange format. |
cmpr |
Another realization, organized around blocks, events, wants, working memory, and code-generation workflows. |
A raw application of patterns in P to the current support state T produces a provisional
next state T'. The stronger semantic claim is that the program has not finished at T'.
It finishes only when further dynamics resolve event-space dissatisfaction into a settled state T*.
On this view, oversupport and undersupport are not just diagnostics produced by an external runner. They are internal signs that the program has not yet reached an admissible meaning. In the ambitious direction, surprise and response-to-surprise belong inside the program.