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 other non-limb plans a direct entry point to the selected structural or generic kernel.
A closed ExecFloat.Binary call can therefore specialize that kernel to its descriptor.
The priorities encode capability preference and carry no numerical meaning, because every candidate must supply the same refinement contract before it can be selected. All of this wiring lives in this module, so storage-specific instances do not leak into 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 use the representation-independent instances above.
First-order entry points #
A machine-word or pair plan calls its structural kernel directly when that candidate wins against the generic kernel under the policy in scope. Non-byte, non-limb plans also expose a direct call when the generic kernel wins. Byte tables, limb candidates, and the remaining structural routes execute the memoized 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 never justifies a route.
The direct square root for a built-in carrier: stored two-word codes where the NativePair layout
allows, otherwise the structural candidate.
Instances For
The direct square root computes the structural candidate's result.
The direct fused multiply-add for a built-in carrier: stored two-word codes where the NativePair
layout allows, otherwise the structural candidate.
Instances For
The direct fused multiply-add computes the structural candidate's result.
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.
Its priority is below codecForPlan because ModelCodec.Code is an output parameter, so
unresolved codec goals must try the generic plan before the concrete limb carrier. That keeps
inference working for conversions between definitionally equal descriptors such as
Binary.descriptor 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.