Incorporating User Interaction into Imperative Languages

In this paper, we present two new forms of the $write$ statement: one of the form $write(x);G$ where $G$ is a statement and the other of the form $write(x);D$ where $D$ is a module. The former is a generalization of traditional $write$ statement and is quite useful. The latter is useful for implementing interactive modules.

💡 Research Summary

The paper proposes two novel extensions to the traditional write statement in C‑like imperative languages, aiming to embed interactive capabilities directly into the language syntax and semantics. The first form, write(x); G, generalizes the classic output operation: the runtime system (or an automated choice mechanism) finds a suitable value v for the variable x such that the subsequent statement G can be successfully executed. In effect, write(x); G behaves like a declarative “assign a value to x that makes G succeed” construct. The second form, write(x); D, treats write as an interactive input declaration inside a module D. When the module is loaded, the interpreter prompts the user (or reads from an external source) to supply a concrete value for x; this value is then substituted throughout D before any further execution.

The language is defined as a small core of untyped C enriched with three syntactic categories:

• G‑formulas (statements): true, atomic procedure calls A, assignments x = exp, sequential composition G; G, and the new write(x); G.
• D‑formulas (procedure declarations): single definitions A = G, universal quantification ∀x D, and conjunction D ∧ D.
• E‑formulas (interactive modules): either a plain D or a D that contains one or more write declarations.

A program is a pair <E, θ> where θ is the current machine state (a set of variable‑value bindings). Execution proceeds via a two‑phase transition system:

1. Execution phase (ex) – reduces a statement G in the context of a program P to a new program P'. Rules cover trivial success (true), assignment evaluation, sequential composition, and crucially rule (9) for write(x); G1. This rule nondeterministically chooses a value v for x, prints it (mirroring traditional output), substitutes v for x in G1, and continues execution.

2. Back‑chaining phase (bc) – handles procedure calls. When a call A is encountered, bc searches the module D for a matching definition, possibly instantiating universally quantified variables (rule (2)) and decomposing conjunctions (rules (3)–(4)). Once a matching clause A = G is found, control returns to the execution phase to run G.

The initialization phase (exec) is invoked when a module containing write declarations is loaded. All write(x_i) statements are replaced by concrete inputs y_i obtained from the environment (rule (10)). After this substitution, the program behaves like ordinary C code, with the added benefit that the values of the formerly declared interactive variables are now fixed.

The paper illustrates the approach with two examples. The first models a phone‑number lookup: write(y); phone(x) = … where y is supplied at runtime for a particular employee (Kim). The second demonstrates age determination for three employees using three successive write statements (y1, y2, y3). In both cases, the interactive inputs are collected before execution, after which the program proceeds with standard control flow (switch statements, assignments, etc.).

In the discussion, the authors argue that write(x); S can be seen as a generalization of the traditional write(exp) because the latter is equivalent to write(x); x == exp when Boolean expressions are allowed as statements. They also emphasize that interactive modules constitute an essential tool for modern interactive programming, enabling a clean separation between module definition and runtime parameter acquisition.

From a theoretical standpoint, the operational semantics borrow heavily from natural semantics (Kahn) and uniform proof theory (Miller, Nadathur, Pfenning). The write construct acts as a logical “assumption” that can be introduced dynamically during proof search, aligning program execution with proof construction in computability logic.

However, the proposal leaves several practical issues open. The nondeterministic choice of v in write(x); G must be resolved by a concrete UI or policy in real implementations; scaling to many interactive variables may complicate input management; and the current formulation only handles scalar variables, not complex data structures such as arrays or structs. Extending the mechanism to richer types and integrating it with existing IDEs would be natural next steps.

Overall, the paper contributes a concise yet expressive extension to imperative languages that embeds interactive input directly into the language’s syntax and semantics, offering a declarative way to acquire runtime data without breaking the procedural flow. It bridges imperative programming with logical proof‑theoretic concepts, opening avenues for formally verified interactive software.