Effect4

R5: Services: the service table, layers and provisionreq:R5

Requirement R5: Services and layer provisionabout:req:R5

This page explains requirement R5 in Effect4. It covers what the requirement asks for service tables and layers, why static requirement grading matters, and how the property is checked.

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

Requirement R5 demands that services are managed through static service tables in the application typing signature and discharged by layers (docs/core/system-map.md §8):

  • Service tables: service keys and types form an explicit static component of Σ_app.
  • Value typing: constructed layer values must fit their declared service keys.
  • Flat coeffect grading: requirement rows grade programs by the service keys they need for execution.
  • Capability discharge: providing a layer discharges its output requirement keys.

A program with an unfilled service requirement must not execute at the top level.

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

Enterprise applications structure dependencies using modular layers that construct database clients, loggers, and authentication handlers.

If requirement rows were untracked, a program could fail at runtime with missing service defects deep inside execution.

Grading a program by its requirement row lets the checker refuse a missing service before the run begins.

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

The requirement is checked by proving layer construction, requirement discharge, and context algebra theorems:

  • Totality of layer building under satisfying contexts is stated by build_total (src/Effect4/Laws/Program/BuildTotal.lean).
  • Capability discharge under layer provision is stated by provide_discharges (src/Effect4/Program/Provision.lean).
  • Closure of layer composition is stated by provide_closed in the same file.
  • Commutativity of row merging is stated by merge_rows_comm in the same file.

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

unauthorized_calls_nothingmodulobound_in_treemodulorequest_leadsgoal
The open part of R5: its planned goals and the theorems proved modulo them. An arrow goes from a node to a node its proof reaches first.
The figure in words
R5 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
build_totalproved—satisfies_union, satisfies_weaken, satisfies_empty
expanded_refs_nil_of_wfproved——
typeOfProgram_expandRefsproved—expanded_refs_nil_of_wf
tree_needs_tokenproved——
unauthorized_calls_nothingmodulorequest_leadstree_needs_token, bound_in_tree, checkInput_eq_none_iff
satisfies_unionproved——
satisfies_weakenproved——
satisfies_emptyproved——
bound_in_treemodulorequest_leadsdenoteRowsB_straight, localWaitC_to_rowsB, request_leads, driveState_lift, evaluatePrim_producer, reached
checkInput_eq_none_iffproved——
denoteRowsB_straightproved——
localWaitC_to_rowsBproved—localRunC_compileBO
request_leadsgoalrequest_leads—
driveState_liftproved——
evaluatePrim_producerproved——
reachedproved——
localRunC_compileBOproved—compilesBO_onExit, compilesBO_matchCause, compilesBO_catchIf, compilesBO_catchCause, compilesBO_select, compilesBO_bind, compilesBO_iterate, compilesBO_exit, compilesBO_suspend, denoteRowsB_straight, denoteRows_straight
compilesBO_onExitproved—at_append
compilesBO_matchCauseproved—at_append
compilesBO_catchIfproved—at_append
compilesBO_catchCauseproved—at_append
compilesBO_selectproved—at_append
compilesBO_bindproved—at_append
compilesBO_iterateproved—at_append
compilesBO_exitproved—denoteRowsB_straight, at_append
compilesBO_suspendproved—at_append
denoteRows_straightproved——
at_appendproved——