Section 46: Dynamic Dispatch, Reflection, and Runtime Introspection¶

TECHSPEC-46 — Section 46 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Purpose¶

Dynamic dispatch selects an implementation at runtime. Reflection and introspection expose information about program structures while the program executes.

These facilities must preserve the language's type, contract, effect, permission, and ownership rules.

2. Dynamic Dispatch¶

Dynamic dispatch may be used where a value is accessed through an explicitly declared interface or trait.

Rules: - The runtime target must implement the required interface. - The selected target must be compatible with the call signature. - The call must preserve required preconditions and postconditions. - Effects and failure types must remain within the declared interface contract. - Ambiguous or invalid targets must fail explicitly.

3. Reflection¶

Reflection may expose: - Module and type identities. - Public function signatures. - Interface implementations. - Declared contracts. - Declared effects and permissions. - Selected runtime metadata. - Available verification records.

Private implementation details are not exposed unless explicitly authorized.

4. Runtime Type Inspection¶

Dynamic values must carry sufficient type identity to validate permitted operations.

A runtime type check establishes the type observed at that point. It does not establish that the value is trusted, authorized, or behaviorally correct.

5. Dynamic Invocation¶

Dynamic invocation must validate: - Target existence and visibility. - Argument count and types. - Required interface compatibility. - Preconditions. - Permissions. - Effect constraints. - Return and failure types.

Invalid invocation must return or raise a defined language-level failure.

6. Dynamic Loading¶

Dynamically loaded modules require: - Explicit loading permission. - Package identity and version. - Integrity and provenance checks. - Interface compatibility checks. - Declared effects and permissions. - A record of the loaded artifact.

Successful loading does not establish behavioral correctness.

7. Restrictions¶

Reflection must not: - Bypass private visibility. - Mutate immutable values. - Bypass ownership or borrowing. - Forge verification evidence. - Grant permissions. - Invoke untrusted code without the required isolation and authorization.

8. Verification Reporting¶

Reports distinguish static metadata, runtime observations, dynamic validation, executed behavior, and unknown properties.

9. MVP Scope¶

The MVP should provide compiler-time introspection and minimal runtime type identity. General reflection and dynamic loading are deferred.

10. Design Goal¶

Dynamic behavior must remain explicit and inspectable. Runtime flexibility must not become a route around compile-time guarantees.

Source file: TECHSPEC-46.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.