Language Support for Adaptation: Intent-Driven Programming in FAST

Adam Duracz; Ahsan Pervaiz; Dung Nguyen; Ferenc A. Bartha; Henry Hoffmann; Krishna V. Palem; Robert Cartwright; Ryuichi Sai; Saeid Barati; Yao-Hsiang Yang

arxiv: 1907.08695 · v1 · pith:X5FIGDIFnew · submitted 2019-07-12 · 💻 cs.PL

Language Support for Adaptation: Intent-Driven Programming in FAST

Yao-Hsiang Yang , Adam Duracz , Ferenc A. Bartha , Ryuichi Sai , Ahsan Pervaiz , Saeid Barati , Dung Nguyen , Robert Cartwright

show 2 more authors

Henry Hoffmann Krishna V. Palem

This is my paper

Pith reviewed 2026-05-24 21:45 UTC · model grok-4.3

classification 💻 cs.PL

keywords intent-driven programmingadaptive computingprogramming languagesruntime adaptationSwiftFAST

0 comments

The pith

The meaning of a program can depend on an accompanying intent specification that modifies its execution dynamically to satisfy properties like resource usage and accuracy.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper introduces intent-driven programming, where programs are paired with intent specifications that alter their standard meaning during runtime to meet additional goals. These goals cover both how resources are used and the quality of results produced. The FAST language demonstrates this by extending Swift with components that compile intents, profile execution, control adaptation, and support legacy code. A reader would care if this model enables portable yet adaptive software that responds to changing conditions without manual intervention for each platform.

Core claim

The meaning of a program additionally depends on an accompanying intent specification expressing how the ordinary program meaning is dynamically modified during execution to satisfy additional properties expressed by the intent, including both intensional properties such as resource usage and extensional properties such as accuracy of the computed answer.

What carries the argument

The intent specification and its enforcement through an intent compiler, profiler, general controller interface, and runtime module in the FAST language.

If this is right

Programs become portable while still adapting to specific hardware and software platforms.
Adaptation occurs dynamically to changes in both the operating environment and the intent itself.
Procedural control can be combined with feedback and optimization-based control.
Interoperation with legacy C/C++ codes is supported in an adaptive setting.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Such a model might reduce the need for platform-specific code branches in applications.
It could be extended to other languages to support similar runtime modifications.
Empirical tests could measure the overhead of intent enforcement in real-world scenarios like varying memory constraints.

Load-bearing premise

That an intent specification can be compiled and enforced at runtime by the described components in a way that achieves dynamic adaptation without prohibitive overhead or loss of correctness.

What would settle it

A demonstration that the runtime adaptation fails to respond to changes in environment or intent, or incurs overhead that makes it impractical for intended uses.

read the original abstract

Historically, programming language semantics has focused on assigning a precise mathematical meaning to programs. That meaning is a function from the program's input domain to its output domain determined solely by its syntactic structure. Such a semantics, fosters the development of portable applications which are oblivious to the performance characteristics and limitations (such as a maximum memory footprint) of particular hardware and software platforms. This paper introduces the idea of intent-driven programming where the meaning of a program additionally depends on an accompanying intent specification expressing how the ordinary program meaning is dynamically modified during execution to satisfy additional properties expressed by the intent. These include both intensional properties---e.g., resource usage---and extensional properties---e.g., accuracy of the computed answer. To demonstrate the intent-driven programming model's value, this paper presents a general-purpose intent-driven programming language---called FAST---implemented as an extension of Swift. FAST consists of an intent compiler, a profiler, a general controller interface and a runtime module which supports interoperation with legacy C/C++ codes. Compared to existing frameworks for adaptive computing, \FAST{} supports dynamic adaptation to changes both in the operating environment and in the intent itself, and enables the mixing of procedural control and control based on feedback and optimization.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

FAST adds intent specs to Swift for runtime adaptation of accuracy and resources, but the work supplies no measurements or formal model to show the controller preserves semantics or keeps overhead reasonable.

read the letter

The main takeaway is that this paper defines intent-driven programming, where a program's meaning now also depends on a separate intent specification that can change at runtime to adjust intensional properties like resource use or extensional ones like answer accuracy. FAST is the Swift extension that tries to make this work through an intent compiler, profiler, controller, and runtime module that also talks to legacy C/C++ code. It claims to handle both environment changes and intent changes themselves, and to mix procedural control with feedback loops. That is the concrete new piece relative to prior adaptive frameworks mentioned in the abstract. The architecture description is clear enough on paper and gives a plausible way to layer intent control on top of an existing language. The interoperation story is a practical plus. The soft spot is exactly where the stress-test note points: there is no formal semantics for how the intent compiler and controller recompile or adjust on the fly without introducing inconsistency, and no measurements of overhead or correctness under changing intents. The central claim therefore rests on an untested assumption that the runtime pieces can deliver adaptation without prohibitive cost or loss of original program meaning. That gap is not minor; it is load-bearing for the whole idea. This is aimed at programming-language researchers who already work on adaptive or self-tuning systems. A reader in that niche could extract the high-level design and the contrast with existing frameworks. It is coherent on its own terms and shows honest engagement with the problem of making adaptation language-level rather than framework-level, so it deserves a serious referee even though the current version is thin on evidence. I would send it to review but flag the need for either a formal model or concrete evaluation results before acceptance.

Referee Report

3 major / 1 minor

Summary. The paper introduces intent-driven programming, in which a program's standard input-to-output semantics is augmented by an accompanying intent specification that dynamically modifies execution to satisfy additional intensional properties (e.g., resource usage) and extensional properties (e.g., answer accuracy). It presents FAST, an extension of Swift, consisting of an intent compiler, profiler, general controller interface, and runtime module that supports legacy C/C++ interoperation; the central claim is that this architecture enables dynamic adaptation both to changes in the operating environment and to changes in the intent itself while mixing procedural and feedback-based control.

Significance. If substantiated, the work would offer a language-level mechanism for adaptive computing that explicitly separates and dynamically reconciles ordinary program meaning from intent-driven constraints, potentially improving upon existing frameworks by supporting on-the-fly intent changes and legacy-code mixing. The conceptual distinction between intensional and extensional properties is a useful framing, but the manuscript supplies no formal semantics, machine-checked proofs, reproducible implementations, or empirical measurements, so the practical significance cannot yet be assessed.

major comments (3)

[Abstract] Abstract: the claim that FAST 'supports dynamic adaptation to changes both in the operating environment and in the intent itself' is load-bearing for the contribution, yet the manuscript provides neither a formal semantics for how intent specifications modify program meaning nor any argument that re-compilation on intent change preserves the original semantics or avoids semantic inconsistency.
[Abstract] Abstract (system architecture paragraph): no model, cost analysis, or correctness argument is given for the interaction among the intent compiler, profiler, controller, and runtime module when an intent is updated at runtime; the weakest assumption that such enforcement can be performed without prohibitive overhead or loss of correctness therefore remains unexamined.
[Abstract] Abstract: the assertion that FAST 'enables the mixing of procedural control and control based on feedback and optimization' is presented without any concrete example, interface definition, or demonstration that the controller interface actually composes the two styles while respecting both the original program semantics and the active intent.

minor comments (1)

[Abstract] The LaTeX macro for the system name appears inconsistently as both FAST and {FAST}; standardize notation throughout.

Simulated Author's Rebuttal

3 responses · 1 unresolved

We thank the referee for the detailed and constructive comments. We respond point by point to the major comments below, acknowledging gaps in the current manuscript while clarifying the scope of this systems-oriented paper on the FAST language extension.

read point-by-point responses

Referee: Abstract: the claim that FAST 'supports dynamic adaptation to changes both in the operating environment and in the intent itself' is load-bearing for the contribution, yet the manuscript provides neither a formal semantics for how intent specifications modify program meaning nor any argument that re-compilation on intent change preserves the original semantics or avoids semantic inconsistency.

Authors: We agree that the manuscript does not supply a formal semantics or preservation arguments. The paper's primary contribution is the design and implementation of FAST as a Swift extension supporting intent-driven adaptation in practice. We will revise the abstract to avoid overclaiming formal properties and add an informal discussion of how intents modify execution in the revised version. revision: partial
Referee: Abstract (system architecture paragraph): no model, cost analysis, or correctness argument is given for the interaction among the intent compiler, profiler, controller, and runtime module when an intent is updated at runtime; the weakest assumption that such enforcement can be performed without prohibitive overhead or loss of correctness therefore remains unexamined.

Authors: The manuscript describes the component interactions at a high level but indeed omits a cost model or correctness argument for runtime intent updates. We will add a new subsection providing a high-level interaction model and overhead estimates in the revised manuscript. revision: yes
Referee: Abstract: the assertion that FAST 'enables the mixing of procedural control and control based on feedback and optimization' is presented without any concrete example, interface definition, or demonstration that the controller interface actually composes the two styles while respecting both the original program semantics and the active intent.

Authors: While the implementation section details the controller interface, we acknowledge the abstract claim would be strengthened by an explicit example. We will insert a concise illustrative example of mixed control styles into the abstract and introduction of the revised manuscript. revision: yes

standing simulated objections not resolved

Formal semantics for how intent specifications modify program meaning together with arguments or proofs that recompilation on intent change preserves original semantics

Circularity Check

0 steps flagged

No circularity; definitional introduction of intent-driven programming with no equations or self-referential reductions

full rationale

The paper defines intent-driven programming as an extension where program meaning depends on an accompanying intent specification, then describes FAST as its implementation in Swift. No equations, fitted parameters, predictions, or uniqueness theorems appear. No self-citations are used to justify load-bearing claims. The central contribution is a new semantic model and language feature, self-contained by definition rather than derived from prior fitted results or author-specific theorems.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claim rests on the domain assumption that traditional semantics are input-output functions determined solely by syntax and on the feasibility of runtime enforcement of intent specifications; no free parameters or invented physical entities are introduced.

axioms (1)

domain assumption Programming language semantics has focused on assigning a precise mathematical meaning to programs as a function from input domain to output domain determined solely by syntactic structure.
Stated explicitly in the opening sentence of the abstract as the historical focus being extended.

invented entities (1)

intent specification no independent evidence
purpose: To express how ordinary program meaning is dynamically modified during execution to satisfy additional intensional and extensional properties.
Core new construct introduced to define the intent-driven model; no independent evidence outside the paper is provided.

pith-pipeline@v0.9.0 · 5775 in / 1342 out tokens · 25574 ms · 2026-05-24T21:45:32.542151+00:00 · methodology

Language Support for Adaptation: Intent-Driven Programming in FAST

Core claim

What carries the argument

If this is right

Where Pith is reading between the lines

Load-bearing premise

What would settle it

discussion (0)