View Contract Demos
These demos exercise the finalized View Contract stack in lib/view.tri:
portable View Trees/checkable typed-program nodes, structural View flow checks,
runtime guarded Views, checked-exec, source annotations, and module-boundary
View metadata.
End-user guide
Start here. demos/viewContracts.tri is written with normal source annotation
sugar and reads as a short guide to View Contracts: motivating structural
mismatches, explaining plain Views, noting why this is not a full static type
system, and building a custom NonEmptyList guarded View.
tricu check demos/viewContracts.tri
Expected output:
ok
Complete explicit demo
demos/viewContracts/complete.tri shows the same layer from the portable
View Tree/checkable-program side. It uses explicit builders such as
typedValue, typedRequire, and typedApply, and demonstrates contextual guard
diagnostics, observation composition, reachability, and malformed guard output.
tricu eval demos/viewContracts/complete.tri -f decode
Portable checker self-tests
Runs the checker self-test suite carried as ordinary tricu code.
tricu eval demos/viewContracts/selfTests.tri -f decode
Expected output is a list of "ok" strings.
Diagnostic rendering
Shows a strict-mode structural View failure rendered for humans.
tricu eval demos/viewContracts/diagnostic.tri -f decode
Expected output:
"symbol 162 expected List Bool but got List String"
Stdlib-shaped contracts
Checks successful higher-order contracts shaped like common stdlib APIs.
tricu eval demos/viewContracts/stdlibContracts.tri -f decode
Expected output:
["ok", "ok", "ok", "ok", "ok"]
These examples are structural View checks, not runtime guarded checks.
Frontend emission layer
frontendEmission/ documents the portable artifact shape a frontend can emit
after parsing/elaboration. The *.source.txt files are pseudo-source; the
matching *.emitted.tri files are explicit typed-program builder output.
This layer is still instructive because it shows the exact bridge between source syntax and portable View Tree/checkable metadata.
Source syntax sugar
The sourceSyntax/ demos use ergonomic annotations and the tricu check
frontend. The frontend lowers annotations to the same typed-program nodes used by
the explicit demos above, then executes checked-exec so guarded annotations fail
through the portable runner.
Successful check:
tricu check demos/viewContracts/sourceSyntax/success.tri
Expected output:
ok
Labeled diagnostic check:
tricu check demos/viewContracts/sourceSyntax/failure.tri
Expected first failing diagnostic:
symbol 4 (x) expected Bool but got String
If the first definition is fixed or removed, the later application-result failure demonstrates callee-aware labels:
symbol 3 (g application result) expected String but got Bool
Module boundary layer
modules/ shows producer-checked module export Views flowing into a consumer
check as module-boundary evidence. During auto-build, annotated exports are
checked before the module manifest alias is published. Consumers then use the
manifest's View Contract metadata as assumptions, while compatibility is still
judged by lib/view.tri.
tricu check demos/viewContracts/modules/success.tri
# ok
tricu check demos/viewContracts/modules/failure.tri
# symbol 3 (Util.toString application result) expected Bool but got String