Effect4

R3: Data: the type language closed under records and variants as Ty growthreq:R3

Requirement R3: First-order data typesabout:req:R3

This page explains requirement R3 in Effect4. It covers what the requirement asks for records and variants, why structured data types matter, and how the property is checked.

What the requirement asksabout:req:R3:what-it-asks

Requirement R3 asks that the static type language Ty closes under structured first-order data types (docs/core/system-map.md §8, DB-15):

  • Records: represented by a single constructor over field lists sorted in canonical name order (decisions row 119).
  • Variants: tagged union representations with normalized membership (decisions row 130).
  • Maps and tuples: pointwise and key-indexed compound data structures.

Every added constructor must provide its Fits membership rule, exact codecs, catamorphic folds, assignability order, and inhabitance characterization.

Why it mattersabout:req:R3:why-it-matters

Application workflows manipulate rich domain models including structured records, optional attributes, error payloads, and payload classes.

If the type system lacked direct representations for compound data, applications would need informal encodings that escape verification.

Closing Ty under records and variants provides thorough end-to-end verification for realistic application data structures.

How it is checkedabout:req:R3:how-it-is-checked

The requirement is checked by proving algebra, membership, codec, and inhabitance theorems across all constructors:

  • Value membership under normalization is stated by fits_normalize and fits_subN (src/Effect4/Laws/Program/Typed/Membership.lean).
  • Semantic inhabitance equivalence is stated by inhabited_iff_fits in the same file.
  • Exact serialization embeddings are stated by decode_iff (src/Effect4/Laws/Schema/Codec.lean) and ofSchema_exact (src/Effect4/Schema/Bridge.lean).
  • Error payload round-trip fidelity is stated by errOf_valOfErr (src/Effect4/Laws/Program/Admit.lean).

The plan on this page gives each theorem's status and the goals it rests on.

R3 by concept: each concept its nodes are placed at, by tag or by module. An arrow goes where a node's proof reaches a node of another concept.
The figure in words
NodeStatusRests onNearest nodes
checkInput_eq_none_iffproved——
fits_normalizeproved—subN_trans, normalize_idem
fits_subNproved—subN_trans, fits_normalize
inhabited_iff_fitsproved—subN_refl
hom_eq_cata_typroved——
decode_iffproved——
ofSchema_exactproved——
readTerm_printTermproved——
type_metadata_exactproved——
errOf_valOfErrproved—errOf_payload
admitModule_classDeclsproved—checkInput_eq_none_iff
errOf_ne_boom_of_supportedproved—hom_eq_cata_ty, errOf_payload, isPayload_of_hasTy_record
errOf_payloadproved——
isPayload_of_hasTy_recordproved—handles_of_payloadFieldTy
frame_lawsproved——
memberproved——
codec_roundtripproved—decode_encode, member, hom_eq_cata_ty, normalize_idem
subN_transproved——
normalize_idemproved——
subN_reflproved——
handles_of_payloadFieldTyproved——
decode_encodeproved——