Theory MCP_Spec
theory MCP_Spec
imports "Voblint_Framework.DG_Spec_Sound" "Voblint_Domain.Reachability_Lift"
begin
section ‹Many cooperating analyses over one state›
text ‹
Goblint's ‹MCP› runs every activated analysis on its own part of one
combined state (‹mCP.ml› at ‹0dc12d355›). Voblint keeps the combined state
as one type ‹'s›, a record with a field per registered analysis, and a
component as operations on the whole record that touch only its own field.
The activation list chooses which components run; the fields of inactive
analyses are never read.
Every operation of a component receives the query channel of the manager
Goblint hands it, ‹man.ask›, as a function \<^typ>‹channel› from queries to
answers: its query handler (‹S.query man q›), its edge transfers, its entry
(‹S.enter man›) and both stages of its return. The return stages also receive
the callee's channel, which Goblint's normal-call transfer in ‹constraints.ml›
passes as ‹f_ask›.
A handler may therefore ask further queries while it answers, and the channel
that answers them is the one ‹ask_rec› below closes over the combined
state, as Goblint's ‹MCP.query'› does.
The channel is a pure function of the state it describes. A component
therefore neither reads nor publishes globals: the combined state covers
analyses whose operations are local, and effectful analyses run as
specifications of their own (\<^const>‹dgs_query› is the effectful handler).
A component holds only what runs. What its states describe, a set of stores,
is not executable and is supplied beside it wherever soundness is stated,
as \<^class>‹numeric_domain› keeps ‹gamma› out of \<^class>‹executable_domain›.
›