Dynamic Stdlib Resolver
Modules, capabilities, fallbacks, providers, present sets, resolution, and conformance.
Module model
A module is the unit of independence, versioning, and capability declaration.
- Public exports are the API user code calls.
- Internals stay private to the module.
- Providers expose capability implementations to other modules.
- Fallbacks keep each module buildable alone.
Capability model
A capability is the sharing currency between otherwise independent modules.
Capabilities are named, versioned semantic contracts. A provider is valid only if it satisfies the capability signature and behaviour. That is what lets one module reuse another module when both are present without changing what the program does.
- Each capability has a signature.
- Each capability has a semantic contract.
- Each implementation needs conformance tests.
- Resolution must be deterministic.
Resolution
Resolution binds every wanted capability to a provider or to the module's own fallback.
- The present set determines which modules are candidates.
- Granular builds use the reachable present set.
- Monolithic builds can consider the full stdlib.
- Provider choice must not depend on filesystem order or hash-map iteration.
Conformance
The granular and monolithic profiles must be behaviourally identical.
- Fallback implementations must pass the same suite as canonical providers.
- An alone build proves independence.
- A paired build proves sharing does not alter semantics.