---
title: Answer Type Modification (ATM)
url: https://www.emergentmind.com/topics/answer-type-modification-atm
type: topic
---

# Answer Type Modification (ATM)

Searching arXiv for recent and foundational papers on answer-type modification and related effect-handler work.
I’ll look up relevant arXiv records to ground the article.
Answer-type modification (ATM) is the ability of a type system to track that the *answer type* of a computation changes during evaluation. In typed delimited control, this is expressed by judgments of the form $\Gamma \vdash e : \tau \;;\; \alpha,\beta$, meaning that under an initial answer type $\alpha$, evaluating $e$ produces a value of type $\tau$ and modifies the answer type to $\beta$; in algebraic effects and handlers, the same idea is internalized as answer-type annotations on computation types and control effects [1606.06379]. ATM is central to the typing of delimited continuations, shift/reset-style operators, and effect handlers because captured continuations can suspend, resume, discard, duplicate, or recontextualize computations in ways that alter the type expected by the enclosing context. More recent work further refines ATM into answer-refinement modification (ARM), where only refinements change while the underlying base type remains fixed, and answer-effect modification (AEM), where temporal effects rather than ordinary result types are modified [2307.15463].

## 1. Core definition and formal role

In the surface calculus for typed delimited-control operators $\mathsf{shift}$ and $\mathsf{reset}$, ATM is introduced by replacing the ordinary judgment $\Gamma \vdash e : \tau$ with $\Gamma \vdash e : \tau \;;\; \alpha,\beta$. The intended meaning is explicit: evaluation starts in an ambient answer type $\alpha$ and ends in an answer type $\beta$. This is the sense in which ATM “modifies” answers rather than merely returning values. The same paper gives the effectful function type $(\sigma/\beta\to\tau/\gamma)$, meaning a function that takes a $\sigma$ and, under answer type $\beta$, returns a $\tau$ while changing the answer type to $\gamma$ [1606.06379].

In effect-handler calculi, ATM is encoded directly in computation types. One formulation uses
$\rho ::= \tau \mathbin{/} \mathsf{pure} \mid \tau \mathbin{/} (\rho_1 \Rightarrow \rho_2)$,
where $\tau \mathbin{/} \mathsf{pure}$ is a pure computation returning $\tau$, and $\tau \mathbin{/} (\rho_1 \Rightarrow \rho_2)$ is an effectful computation that changes its answer type from $\rho_1$ to $\rho_2$. Another formulation packages the same information as a control effect
$$
S ::= \Box \mid \mathsf{ctl}\ x . C_1 \Rightarrow C_2,
$$
where $\Box$ means “no operation,” and $\mathsf{ctl}\ x . C_1 \Rightarrow C_2$ means that when the computation is plugged into a context expecting answer type $C_1$, with $x$ bound to the computation’s result, the handler will see answer type $C_2$ [2508.12572].

ATM is therefore not merely a property of operators such as $\mathsf{shift}$ or of a specific handler clause. It is a typing discipline for the interaction between a computation and its surrounding context. This suggests that ATM is best understood as a structured account of *context transformation*: the program does not simply produce a value, but changes what the rest of the computation is allowed or required to be.

## 2. Typing judgments, subtyping, and handler interaction

A recurring feature of ATM systems is that computation types carry both a return component and an answer-type transformation. In the effect-handler setting, the judgment
$$
\Gamma \vdash_{\mathsf{ATM}} c : \rho
$$
assigns to a computation a type $\rho$ that may be pure or may carry an annotation $(\rho_1 \Rightarrow \rho_2)$. In the refinement-based system for OCaml-5-style algebraic effects, the corresponding judgment is
$$
\Gamma \vdash c : \mathsf{Comp}(\Sigma, T, S),
$$
where $\Sigma$ is an operation signature, $T$ is a return type, and $S$ is a control effect. The operation rule has the form
$$
\Gamma \vdash op^{\bar A} v : \mathsf{Comp}(\Sigma, T_2[\bar A/\bar X][v/x], \mathsf{ctl}\ y . C_1[\bar A/\bar X][v/x] \Rightarrow C_2[\bar A/\bar X][v/x]),
$$
which makes ATM visible already at the point of invoking an effectful operation [2307.15463].

Subtyping is the technical device that allows ATM to compose. In the finitary PCF system, the key rules include:

- $(S\text{-Pure})$: $\tau_1 \le \tau_2 \Rightarrow \tau_1/\mathsf{pure} \le \tau_2/\mathsf{pure}$.
- $(S\text{-Ipure})$: $\tau_1 \le \tau_2$, $\rho_2 \le \rho_1$, and $\rho_1' \le \rho_2'$ imply
  $\tau_1/(\rho_1 \Rightarrow \rho_1') \le \tau_2/(\rho_2 \Rightarrow \rho_2')$.
- $(S\text{-Embed})$: $\tau_1 \le \tau_2$ and $\rho_1 \le \rho_2$ imply
  $\tau_1/\mathsf{pure} \le \tau_2/(\rho_1 \Rightarrow \rho_2)$.

The last rule is especially important because it says that any pure computation may be viewed as an effectful one, provided subtyping holds on results and answer types. In the refinement formulation, the corresponding embedding rule is
$$
\Gamma,x:T \vdash C_1 <: C_2,\ x \notin FV(C_2)
\;\Rightarrow\;
\Gamma \mid T \vdash \Box <: \mathsf{ctl}\ x . C_1 \Rightarrow C_2,
$$
and the core ATM subtyping rule weakens assumptions contravariantly and guarantees covariantly on answer types [2508.12572].

Handler typing is where ATM departs most sharply from no-ATM systems. Under a standard no-ATM system, every clause of a handler—both the return clause and each op-clause—must produce the same answer type. ATM frees the typing discipline from that requirement. In the finitary PCF account, each operation $op_i$ may have its own answer type $\rho_i'$, and the `with-handle` construct itself may modify the ambient answer type from $\rho$ to $\rho'$. In the refinement system, a handler transforms a computation typed as $\mathsf{Comp}(\Sigma, T, \mathsf{ctl}\ x_r . C_1 \Rightarrow C_2)$ into $\mathsf{Comp}(\emptyset, C_2)$ once the return clause is checked at $C_1$ and each operation clause is checked against its own continuation type [2307.15463].

## 3. ATM in algebraic effects, handlers, and refinement typing

The refinement-type system for algebraic effects and handlers was proposed to address what the paper describes as the absence of a satisfactory refinement type system for algebraic effects and handlers. Its central claim is that the expressivity and usefulness of algebraic effects and handlers come from their ability to manipulate delimited continuations, but those same continuations complicate control flow and make verification harder. The proposed solution is ARM, a notion that allows the refinement type system to precisely track what effects occur and in what order when a program is executed, and to reflect such information as modifications to the refinements in the types of delimited continuations [2307.15463].

The distinction between ATM and ARM is explicit. Full ATM allows the entire answer type $C_1 \Rightarrow C_2$ of a computation to change. ARM is the restricted case where only the refinement part of a base-type answer changes and the underlying base type itself remains the same. The paper states that the system supports full ATM, but that in “ordinary” verification style one typically only needs ARM, namely the case where $C_1$ and $C_2$ have the same base type but different refinements.

A worked OCaml-5 example, “choose-max,” shows how ATM is used to verify a nondeterministic program:

```ocaml
let h = { return x ↦ return x ;
          effect decide() k →
            let t = k true in
            let f = k false in
            return (max t f)
        }

let prog = with h handle
  let a = if perform decide() then 10 else 20 in
  let b = if perform decide() then 1  else 2  in
  return (a - b)
```

The account states that every call `perform decide()` has a type of the form
$\mathsf{Comp}(\{\mathsf{decide} : \forall X.(\mathsf{unit}\to((\mathsf{bool}\to\mathsf{Comp}(\Sigma,\mathsf{int},\mathsf{ctl}\ y.R_1\Rightarrow R_2))\to R_3))\}, \mathsf{int}, \mathsf{ctl}\ r . R_1 \Rightarrow R_2)$,
where $R_1$ and $R_2$ are refinement types selected by the predicate argument $X$. For the first call, the instantiation
$$
R_1 \equiv z=\mathsf{int}\{z = (\mathsf{if}\ y\ \mathsf{then}\ 10-1\ \mathsf{else}\ 20-2)\}
$$
and
$$
R_2 \equiv \mathsf{int}\{z = 19\}
$$
permits ATM subtyping via $S\text{-ATM}$ to match the handler’s demands, yielding the whole program type $\mathsf{int}\{z = 19\}$. The paper emphasizes that every movement of the answer type from $R_1$ to $R_2$ is recorded by ATM as a whole computation-type change, even though only the refinement changes.

This use of ATM supports an interpretation of handlers as refinement transformers rather than only control delimiters. That interpretation is not stated verbatim, but it is a plausible implication of the way answer-type changes are reflected into continuation types.

## 4. CPS and prompt-passing translations

A major line of work on ATM studies whether ATM can be eliminated by translation into calculi or host languages without native answer-type modification. One result is a typed prompt-passing-style translation from a calculus with $\mathsf{shift}$ and $\mathsf{reset}$ with ATM into a target calculus with multi-prompt $\mathsf{shift}_p$ and $\mathsf{reset}_p$ but no ATM. The translation maps
$$
\llbracket \tau;\alpha,\beta \rrbracket = \beta \to \alpha \to \tau
$$
and
$$
\llbracket \sigma/\alpha\to\tau/\beta \rrbracket
= \llbracket \sigma \rrbracket \to \llbracket \tau;\alpha,\beta \rrbracket.
$$
It creates two fresh prompts at each source-level reset, with one prompt corresponding to the new answer type after the reset and the other to the old one. The paper proves that the translation preserves typing and gives an optimized translation that generates prompts only when needed [1606.06379].

The same elimination idea reappears for algebraic effects and handlers in CPS form. In the ATM-typable finitary PCF setting, types are translated by
$$
\llbracket b \rrbracket = b,\qquad
\llbracket \tau_1 \to (\tau_2/\mathsf{pure}) \rrbracket = \llbracket \tau_1 \rrbracket \to \llbracket \tau_2 \rrbracket,
$$
$$
\llbracket \tau/\mathsf{pure} \rrbracket = \llbracket \tau \rrbracket,\qquad
\llbracket \tau/(\rho_1 \Rightarrow \rho_2) \rrbracket
= \llbracket \Sigma \rrbracket \to (\llbracket \tau \rrbracket \to \llbracket \rho_1 \rrbracket) \to \llbracket \rho_2 \rrbracket.
$$
Here $\llbracket \Sigma \rrbracket$ is a record type encoding the operation signature. Operation invocation becomes record lookup and direct call, and `withhandle` constructs are compiled by supplying a record of handler bodies together with the continuation for the previous answer type. The paper describes this CPS as derivation-directed: each subtyping or typing derivation is turned into a target term [2508.12572].

The refinement-type paper for algebraic effects and handlers also proves bidirectional refinement-type preservation for its CPS transformation. The statements are:

- Forward preservation: if $\Gamma \vdash c : C$ then $\vdash \mathsf{cps}(c) : \mathsf{cps}(C)$.
- Backward preservation: if $\vdash \mathsf{cps}(c) : \tau$ in the handler-free target system, then there is some $C$ in the source such that $\vdash c : C$ and $\mathsf{cps}(C) <: \tau$.
- Simulation: $c \Downarrow \mathsf{return}\ v \Leftrightarrow \mathsf{cps}(c) \Downarrow \mathsf{cps}(v)$.

These results show that ATM is not only a source-language typing discipline; it can also serve as a guide for semantics-preserving translations to handler-free or no-ATM targets. The data additionally states that the 2016 prompt-passing work generalizes Kiselyov’s direct-style implementation of typed `printf`, which uses two prompts to emulate the modification of answer types.

## 5. Verification, soundness, decidability, and termination

ATM has been used as a verification mechanism, not only as a typing convenience. In the refinement system for algebraic effects and handlers, the main meta-theoretic result is type safety in the form of subject-reduction and progress: if $\vdash c : \mathsf{Comp}(\Sigma,T,S)$ and $c \to^* c'$, then either $c' = \mathsf{return}\ v$ with $\vdash v : T$, or $c' = K[op\ v]$ for some $op \in \Sigma$, or $c'$ can step further. The proof sketch uses standard induction on evaluation together with $S\text{-ATM}$ to justify contravariant and covariant manipulations of answer types [2307.15463].

In temporal verification, the corresponding notion is answer-effect modification rather than answer-type modification. The system extends temporal effects to shift$_0$/reset$_0$ by giving computations a temporal effect $\Phi$ together with a control effect $S$, written
$$
\Gamma \vdash e : T \;\anp\; \Phi \;/\; S.
$$
The control effect is either $\Box$ or $(\forall x.C_1)\Rightarrow C_2$. The key interpretation is that $C_1$ records what the captured continuation’s context must satisfy, while $C_2$ records what the enclosing reset$_0$ expects. The paper proves soundness for finite event sequences via type safety and for infinite event sequences using a logical relation, and emphasizes that AEM enables reasoning about traces yielded by captured continuations [2207.10386].

A different consequence of ATM appears in finitary PCF with effect handlers. The paper proves the theorem: if $c$ is a closed ATM-typable finitary PCF program with effect handlers, then deciding whether $c \to^* \mathsf{return}\ \mathsf{true}$ holds is decidable. The proof proceeds by CPS-transforming $c$ into a simply-typed, handler-free finitary PCF program $c^*$, using typability preservation and simulation, and then appealing to the known decidability of reachability in plain simply-typed, handler-free finitary PCF due to Ong ’06 and Kobayashi ’09 [2508.12572].

The same paper also proves that any ATM-typable nonrecursive finitary PCF program with effect handlers is strongly normalizing. The argument is that if the source has no recursion, then its CPS transform also has no recursion; the target is then an ordinary simply-typed $\lambda$-calculus term with records and without recursion or effects, hence strongly normalizing; simulation transfers termination back to the source.

## 6. Expressiveness, restrictions, and related notions

ATM is sometimes presented as increasing expressiveness because it permits programs that standard no-ATM systems cannot type. The finitary PCF work confirms this intuition by exhibiting programs typable with ATM but not without it. One example is
$$
c_3 \;\triangleq\;
\mathsf{let}\ r = \mathsf{with}\ \{
\mathsf{return}\ x = x,\;
op\ x\ k = k\ x;\ \mathsf{true}
\}\ \mathsf{handle}\ (op\ (); ())\ \mathsf{in}\ \mathsf{if}\ r\ \mathsf{then}\ \mathsf{true}\ \mathsf{else}\ \mathsf{false}.
$$
The paper states that no-ATM simple typing fails because the return clause body `x` has type `unit` while the op-clause body `(k x; true)` has type `bool`, and the standard handler rule requires a single answer type for all clauses. ATM succeeds by assigning
$$
op : unit \to bool \mathbin{/}(unit \mathbin{/}\mathsf{pure} \Rightarrow bool \mathbin{/}\mathsf{pure}).
$$
This is a direct instance of ATM enabling distinct answer types in return and op clauses [2508.12572].

The same paper also shows the converse: there are programs typable without ATM that become untypable with ATM. Its example is
$$
c_4 \;\triangleq\; \mathsf{rec}\ f = \lambda\_.\ \mathsf{with}\ h\ \mathsf{in}\ f\ ()
$$
where
$$
h = \{\mathsf{return}\ x = op\ (); \quad op\ x\ k = ()\}.
$$
Under the simple system one can give $f : unit \to unit$ and $op : unit \to unit$, with both clauses producing `unit`. Under ATM, however, the subtyping constraints force the answer-type transformation $\rho_1 \Rightarrow \rho_2$ to become pure, which conflicts with the effectful return clause invoking `op ()`. The paper states that a contradiction follows, so $c_4$ is untypable in ATM.

This bidirectional separation matters for interpretation. ATM is not simply “more permissive” than traditional handler typing. The data explicitly states that there are programs typable with ATM but not without it, and also programs typable without ATM that become untypable with ATM. A plausible implication is that ATM imposes a finer structural discipline on continuations: it enlarges expressiveness along some dimensions while ruling out programs whose control flow cannot be assigned coherent answer-type transformations.

Related notions clarify this landscape. ARM is the case where only refinements change while the underlying base type remains the same [2307.15463]. AEM is the temporal-effect analogue, where what changes is the answer effect of the continuation rather than an ordinary answer type [2207.10386]. Across these variants, the unifying pattern is a require–guarantee view of delimited control: a captured continuation assumes one answer specification before resumption and establishes another afterward.

Source: https://www.emergentmind.com/topics/answer-type-modification-atm