View Contracts at the intensionality boundary

Conclusion

Tree Calculus does not support the abstraction theorem that the former parametric View design assumed. Views can remain useful as boundary metadata and as instructions for runtime guard placement, but they must not be presented as types, proofs of parametricity, or representation-hiding abstraction.

Fundamental conflicts

Raw observation defeats representation independence

A parametric contract such as:

forall a. a -> a

normally relies on code being unable to learn anything about a. A Tree Calculus term can inspect the tree supplied at a, distinguish representations, and return a representation-dependent value. The View variable does not hide or seal that tree.

The same breaks existential abstraction. Advertising a payload as exists repr. ... changes no operational capability: a client can still inspect the representation directly.

Opaque payloads are asserted, not checked

A typed-value node carries an executable tree beside a View. Metadata validation deliberately treats that executable field as opaque. Consequently, accepting a node proves that the envelope and View are well formed; it does not prove that the tree denotes the advertised Fn, List, Maybe, or other structural View.

Provenance labels do not change this. Checked and Trusted record where an assertion came from, but neither is a derivation that another implementation can replay to establish the assertion.

Syntactic taint is not a semantic parametricity proof

Rejecting direct uses of t or triage is neither complete nor a stable soundness boundary:

an observer can be assembled after reduction;
observation can arrive through higher-order or dynamically selected code;
unknown external code can hide observation;
absence of a rule-3 redex is not reduction-closed;
exact detection would subsume non-trivial termination/reachability questions.

A conservative taint pass can define a programming convention, but it cannot justify the parametric or abstraction guarantees previously attached to Views.

Flow checking only checks represented flow

The checker sees frontend-emitted value, application, and requirement nodes. It can check consistency among those nodes, but it cannot establish that the graph faithfully represents every use performed by the opaque executable payload. This is useful artifact validation, not whole-program typing.

Retained contract

The reduced checker may soundly claim only:

View, node, and program envelopes satisfy their declared data schemas.
Explicit monomorphic View facts are propagated consistently through the represented application graph.
A Guarded View causes its executable predicate to run at represented boundaries, and guard failure prevents checked execution.
Content-addressed references prevent an attached View artifact from silently drifting to a different stored object.

Items 1, 2, and 4 establish metadata integrity, not semantic membership in an unguarded View. Item 3 is the only retained mechanism that observes an ordinary runtime value.

Code direction

The initial rollback therefore:

removes View-variable instantiation, substitution, and unification from the portable checker;
rejects Var, Forall, and Exists as checker inputs while reserving their legacy tags for deterministic decoding;
removes the frontend raw-intensionality taint pass;
removes polymorphic stdlib annotations and value-level View facts;
retains monomorphic View flow, artifact plumbing, diagnostics, and executable guards.

Further simplification should treat unguarded structural Views as descriptive labels. If stronger guarantees are desired later, they require an operational mechanism such as runtime recognizers/seals or a genuinely restricted language whose evaluator enforces the restriction. Metadata provenance alone is insufficient.

3.9 KiB Raw Blame History