Files
tricu/notes/view-contract-trust-provenance.md

123 lines
4.7 KiB
Markdown

# View Contract trust provenance and controlled intensionality
## Problem
Tree Calculus / tricu code can perform raw intensional observation through `t` /
`triage`-like power. Exact detection of whether an arbitrary term ever reaches
rule 3 is undecidable: the SK fragment is already Turing-complete, and a program
can construct/apply an intensional observer iff an encoded machine halts.
Therefore View Contracts must not rely on an exact semantic test for "will this
term inspect representation?".
## Key correction
A purely syntactic invariant such as "the initial tree contains no
`Fork(Fork(_, _), _)`" is not reduction-closed. For example:
```text
Fork (Stem (Fork a b)) c ==> Fork (Fork a b) c
```
So absence of a current rule-3 redex is not enough.
## Direction
Use explicit provenance/capability discipline, not exact intensionality
decision.
View Contract checking and parametric checked-subset validation are distinct:
- View Contract checking: verifies executable tree artifacts against declared
boundary Views.
- Parametric checked-subset validation: verifies that abstraction/parametricity
claims do not depend on raw untrusted intensional observation.
Unchecked/raw Tree Calculus can always inspect trees. Existential/abstract Views
are checker-level opacity: checked clients cannot justify representation-specific
operations unless an exported trusted capability/eliminator provides them.
## Provenance model
Contract facts/artifacts should carry explicit provenance. Do not rely on module
or catalog convention.
Recommended durable provenance classes:
```text
Checked -- derived by checked lowering / checker validation
Trusted -- asserted by a trusted boundary, e.g. a primitive eliminator API
Unchecked -- no abstraction/parametricity guarantee; raw/assumed fact if exposed
```
The correct granularity is per exported View fact, not per module. A single
module may contain checked definitions, trusted eliminators, and unchecked raw
helpers.
## Controlled intensionality
Raw intensionality should be tracked by dependency/provenance, not syntax-only.
- Direct `triage` / arbitrary `t` eliminator use is raw intensional capability.
- Trusted eliminators expose controlled observation and do not taint clients.
- Calling unchecked/untrusted code taints the caller for parametricity purposes.
- Constructors/literals are not automatically tainting unless they expose raw
inspection power.
Parametric checked mode rejects annotated definitions whose derivation depends
on raw/untrusted intensionality, while trusted facts may describe raw internals
behind explicit contracts.
## Trusted eliminator kernel
First trusted observation capabilities should be the smallest useful kernels:
```text
matchBool : forall r. r -> r -> Bool -> r
matchMaybe : forall a r. r -> (a -> r) -> Maybe a -> r
matchList : forall a r. r -> (a -> List a -> r) -> List a -> r
```
Derived functions should be checked against these trusted capabilities where
possible. Raw recursive kernels and other code
that passes through fixed-point/intensional machinery should publish explicit
`Trusted` facts rather than being treated as checked.
Current stdlib shape:
```text
Checked annotations where the body checks through trusted capabilities:
maybeMap : forall a b. (a -> b) -> Maybe a -> Maybe b
maybeBind : forall a b. Maybe a -> (a -> Maybe b) -> Maybe b
maybeOr : forall a. a -> Maybe a -> a
Trusted value-level facts for raw/recursive stdlib boundaries:
headMaybe / lastMaybe / nthMaybe
append / map / filter / foldl / foldr
length / reverse / snoc / count / all? / any? / intersect
take / drop / splitAt / concatMap / find / partition / zipWith
string/list-byte helpers such as strLength, startsWith?, lines, words
```
Do not assign total contracts to partial APIs such as:
```text
head : List a -> a
```
Prefer `headMaybe : List a -> Maybe a`, or later introduce `NonEmptyList a`.
## Implementation order
Most-correct tractable path:
1. Add contract provenance to the Haskell View model and portable artifacts. ✅
2. Preserve provenance through module exports/imports/re-exports. ✅
3. Teach checker environments to distinguish checked vs trusted facts. ✅
4. Add trusted stdlib eliminator facts. ◐ initial value-level `viewFacts` landed for `matchBool`, `matchMaybe`, `matchList`; Haskell trusted catalog removed
5. Add parametric-mode dependency/effect checking. ◐ local raw-dependency and unchecked-import rejection landed
6. Annotate/publish derived stdlib Views at the right provenance. ◐ checked `maybeMap`/`maybeBind`/`maybeOr`; trusted value-level facts for recursive list combinators
Avoid introducing implicit trusted catalogs before provenance exists; that would
create semantics that later need to be unwound.