PLDI Writing Style

A PLDI paper is an engineering argument written for people who will try to break it. The style that survives has three habits: it states the hard case before the solution, it explains mechanisms rather than accumulating adjectives, and it scopes every claim to exactly what the evaluation shows. Since the PACMPL switch, the published object is a journal article in single-column acmsmall — roomier lines than the old two-column look, but the same conference-grade cap on text pages, so the format rewards clarity, not length.

The first-page contract

By the end of page one a reviewer should be able to answer four questions:

1. What breaks today? The concrete program, workload, or proof burden that existing techniques mishandle — shown, ideally, as a small code example.
2. What is the insight? One sentence a compiler writer could act on ("summarize modules by polymorphic escape signatures"), not a property wish ("fast and precise").
3. Does it exist? The implementation substrate — which compiler, which IR, which proof assistant.
4. What is the headline evidence? The number, with its suite and baseline attached, plus the paper's stated limit.

The worked rewrite in resources/worked-examples/01-introduction.md performs this transformation end to end.

Style table: draft reflex → PLDI voice

The running example discipline

Pick one small program that exhibits the hard case and reuse it everywhere: to motivate (§1), to walk the semantics (§3), to show the transformation (§4), and as the first row of the evaluation (§6). One example that a reviewer can trace end-to-end beats five disconnected snippets — and it is the cheapest insurance against the "I could not follow the analysis" review.

Claim ledger

Before the final pass, extract every claim sentence and demand its evidence address:

CLAIM                                    -> EVIDENCE
"sound modulo first-class continuations" -> Thm 2 (§5) + restriction check (§4.4)
"majority of closures stack-allocated"   -> Table 3, 11/14 programs
"under 3% compile-time overhead"         -> Table 5, 30 timed builds, CI
"no whole-program pass required"         -> §4.2 construction, artifact demo

Any claim without an address gets weakened or cut; any evidence without a claim is a candidate for the supplement (pldi-supplementary).

Sentence-level habits

• Present tense for the system's behavior, past tense for the experiments run.
• Name concrete infrastructure ("an LLVM 18 pass", "a Rocq development of 12k lines") — abstraction here reads as evasion.
• Kill the "increasingly popular/important" opener; start at the hard case.
• Define notation once, in a figure, before first use; PLDI reviewers cite notation drift as a soundness smell, not a typo.

Output format

[First-page contract] hard case / insight sentence / substrate / headline number: each present?
[Running example] one program threaded through §1-§6? yes/no
[Claim ledger] n claims, n addressed, list the orphans
[Tone flags] adjectives standing in for mechanisms; apology-style limitations
[Cut list] <sections/paragraphs to compress before the cap does it for you>