Capability instances for configured binary formats #
Representation-independent instances serve custom carriers. Higher-priority instances for
Configured.Code expose byte tables after dependent elimination of the selected storage plan, and
give the machine-word plans and the two-word wide formats a first-order entry point. When the
structural candidate wins, a closed ExecFloat.Binary call can specialize that kernel to its
descriptor.
The priorities encode capability preference, not numerical semantics: every candidate must supply the same refinement contract before it can be selected. Keeping this wiring in one module makes backend choice inspectable and prevents storage-specific instances from leaking through the rest of the configured API.
Higher-priority built-in-carrier instances match Code plan before inspecting the plan. This
works for every statically computed precision, including a forKnownWidth expression that has not
yet reduced to a storage constructor during typeclass indexing. The dependent candidate helpers
then add direct byte tables exactly when the selected plan is .byte.
Families with a custom carrier continue to use the representation-independent instances above.
First-order entry points #
A machine-word or pair plan calls its structural kernel directly only when that candidate wins against the generic kernel under the policy in scope. Otherwise it executes the memoized selection. This includes tiny formats stored in a larger word: their FMA and square-root costs can favor the generic kernel. Byte tables and limb candidates always enter through selection.
The guard stays inside execute so closed callers can specialize the selected kernel. A match
around the capability record would prevent the compiler from reducing the projection before
kernel specialization. The proofs below unfold candidate selection, including the choice between
word and fixed-limb square root and FMA; numerical equivalence alone does not justify a route.
Closed limb plans expose their concrete carrier during typeclass indexing. These instances
forward to the automatic portfolios so ExecFloat.BinaryLimbs retains the policy in scope,
its certified candidates, and the generic fallback.
The canonical lossless codec for the concrete limb carrier.
Keep this below codecForPlan: ModelCodec.Code is an output parameter, so unresolved codec
goals must try the generic plan before the concrete limb carrier. This preserves inference for
conversions between definitionally equal descriptors such as Binary.format 8 23 and binary32.
Policy-selected addition for the concrete limb carrier.
Policy-selected subtraction for the concrete limb carrier.
Policy-selected multiplication for the concrete limb carrier.
Policy-selected division for the concrete limb carrier.
Policy-selected square root for the concrete limb carrier.
Policy-selected fused multiply-add for the concrete limb carrier.