Compact arithmetic detour (bounded)

Question and decision

Can authored SCP perform arithmetic on tricu's existing compact LSB natural-number trees without a frontend arithmetic opcode or inherited tricu lambda implementation? Yes, for successor and two-operand addition. lib/consumer/succ.scp is three structural rules; add.scp has four zero/carry rules and eight bit/carry rules. They compose in demos/consumers/lessons/size/tree-size.scp without unary counts or a state adapter. We retain arithmetic ownership in SCP for these operations. Reconsider the implementation when subsequent real programs expose a specific correctness, clarity or cost problem.

Correctness scope

result/bin/tricu eval test/experiments/scp-arithmetic/check.tri --io \
  --allow-read lib/consumer --format tree
python3 test/scp_native_validation.py result/bin/tricu --directory .bootstrap-run/scp-arithmetic-smoke

The bounded differential compares the independently evaluated structural SCP source, the lexical compiled worker, and tricu's succ/add by exact tree equality. Successor cases include 0, 1, carry boundaries through 4095; addition checks all 256 pairs from 0..15 plus zero, large operands, and carry/asymmetry cases through 4095. The lesson checks 1, 2, 3, and self-size on the compiled executable descriptor (69382 on this build). The cases specify canonical natural trees; malformed bit spines are outside the arithmetic input contract.

Native CAS probe

The former cold-source arithmetic timing driver was removed. Arithmetic source examples remain here; historical measurements can be recovered from Git.

One three-sample probe on this machine/build, using 12 exports in each bundle (four input lengths × control/successor/add). The probe measures these 12-export bundles:

Phase / input	SCP-authored	tricu succ/add
one-time source-to-bundle build	30.25 s	0.38 s
exported bundle	30,912 B	9,343 B
CAS import	59 ms	54 ms
native load-to-READY, add n=255	47.5 ms	45.5 ms
first add n=255	0.91 ms	2.69 ms
subsequent 19 adds, n=255	1.00 ms/call	1.48 ms/call
subsequent 19 successors, n=255	0.78 ms/call	0.70 ms/call
subsequent 19 controls, n=255	0.73 ms/call	0.71 ms/call

The first timing attempt used the same pure argument for all --repeat calls. Its subsequent-call numbers were ~0.02 ms and therefore unusable: the Haskell host could reuse evaluated graph nodes. The retained probe reads fresh bytes from a permitted file on every call, computes length to obtain a runtime compact number, performs arithmetic, and compares its result to a known expected literal, printing only ok. The control does the same read, length, equality, and fixed output without arithmetic. That shared overhead is appreciable relative to successor; timings near control do not resolve a successor speed advantage. The previous decimal-rendered probe also hid addition cost under decimal formatting of 1024+; the retained probe does not. --repeat markers separate CAS load, first call, and later calls. Bundle creation, CAS import, and native load are reported separately.

Crucially, tricu's current add repeatedly uses predecessor/successor; SCP add.scp ripples one bit at a time. The add timings compare these implementations and algorithms. At n=255 successor is near the control overhead; the probe cannot resolve its arithmetic cost at that scale. The one-time SCP source build and code size are substantial despite acceptable native load and call costs. The compact self-size worker descriptor is ~69k tree nodes on this build; the output encoding and executable size have separate costs.

Limits and follow-up

The subsequent countLines.scp migration uses compact counts and supplies an SCP successor descriptor in its initial state; its callers and verified source bundles now explicitly prepare this dependency. A focused follow-up found repeated worker calls on the line-counting hot path more expensive than single arithmetic invocations. countLines-fast.scp is a bounded unshipped two-bit no-carry experiment: it duplicates arithmetic in the text consumer and helps separate per-line call cost from numeric representation. A three-bit variant was probed but discarded when it roughly doubled source build cost without a meaningful further 300-line runtime gain. The maintained base consumer instead composes the successor. A historical single-sample native CAS probe measured ~56 ms/read for 300 lines versus ~14.9 ms for the compact lambda baseline; the SCP source build was ~24.6 s and CAS load ~44 ms. Use paired summary-client measurements for application comparisons. If build size/cost becomes an application obstacle, study optimizations of existing structural patterns and repeated worker embedding before adding numeric source syntax or IR tags.