POPL Skills
A 12-skill depth pack for POPL submissions: venue fit for semantics/types/verification work, HotCRP submission under the 25-page acmsmall cap, full double-blind hygiene, author response, conditional-acceptance revision, mechanized-proof artifact evaluation, PACMPL Issue POPL camera-ready, and the July-to-January campaign calendar. Grounded in the POPL 2027 CFP, popl27.sigplan.org dates, POPL artif
Skills in this plugin
11- ▌ Popl Submission · brycewang-stanfordUse when preparing a POPL submission for the single July HotCRP deadline — auditing the 25-pages-of-text acmsmall cap, summary-rejection format rules, full double-blind hygiene for theory papers with public proof repositories, dual-submission exposure, and the final-days upload order before the AoE cutoff.
- ▌ Popl Experiments · brycewang-stanfordUse when designing the empirical component of a POPL paper — deciding whether evidence should be a mechanization, a prototype, case studies, or benchmarks; reporting proof effort and case-study coverage honestly; and keeping performance numbers in a supporting role so the formal claim stays the paper's center of gravity.
- ▌ Popl Camera Ready · brycewang-stanfordUse when a POPL paper is conditionally accepted — planning the mandatory revision the Review Committee must approve, de-anonymizing for PACMPL Issue POPL, handling ORCID/open-access/APC steps on the ACM side, syncing the paper with its proof artifact, and preparing the January talk.
- ▌ Popl Related Work · brycewang-stanfordUse when positioning a POPL paper in the semantics, type-systems, and verification literature — stating per-line technical deltas against the nearest formal systems, covering the PACMPL family and LICS/CAV/CPP/TOPLAS neighbors, citing PACMPL-era papers in journal form, and dblp-verifying every classic before it is attributed to POPL.
- ▌ Popl Supplementary · brycewang-stanfordUse when splitting a POPL paper across the 25-page body, the proof appendix, and anonymous supplementary material — deciding which proofs and auxiliary judgments leave the text, packaging proof scripts without identity leaks under full double-blind, and keeping every artifact self-consistent with the submission PDF.
- ▌ Popl Writing Style · brycewang-stanfordUse when drafting or revising POPL prose — building the informal-to-formal ramp from a motivating program to definitions to a sharply stated main theorem, keeping notation coherent across 25 pages of text, writing proof sketches that name the hard case, and framing significance as an idea other PL researchers can reuse.
- ▌ Popl Review Process · brycewang-stanfordUse when interpreting where a POPL submission stands — the full double-blind pipeline from the July HotCRP deadline through reviews, the optional author response, October conditional-acceptance decisions, the mandatory revision gate, Distinguished Paper selection, and publication as PACMPL Issue POPL in January.
- ▌ Popl Author Response · brycewang-stanfordUse when drafting a POPL author response during the optional multi-day window — triaging soundness objections against misread definitions, answering "what does Theorem 3 actually assume" questions with pointers rather than new material, staying concise per the CFP, and protecting the path to conditional acceptance.
- ▌ Popl Reproducibility · brycewang-stanfordUse when making a POPL paper's results independently checkable — deciding which theorems to mechanize versus hand-prove, maintaining a paper-to-proof correspondence table from day one, keeping on-paper proofs auditable with explicit assumption tracking, and making any accompanying prototype's numbers regenerable.
- ▌ Popl Topic Selection · brycewang-stanfordUse when deciding whether a project is POPL-shaped — a principle about programming languages carried by definitions and theorems — or better aimed at PLDI's implementation bar, OOPSLA's breadth, ICFP's paradigm focus, or LICS, CAV, CPP, ESOP, and journal outlets, judged by what the decisive evidence is.
- ▌ Popl Artifact Evaluation · brycewang-stanfordUse when packaging a POPL artifact — above all a mechanized proof development in Rocq/Coq, Lean, Agda, or Isabelle — for the post-conditional-acceptance evaluation, satisfying the no-admit/no-sorry completeness rule, mapping paper theorems to proof files, pinning toolchains, and earning the Functional, Reusable, and Available badges.