Please see the Call for Papers tab.

Accepted Papers in Round 1

Title
Accurate Data Race Prediction in the Linux Kernel through Sparse Fourier Learning
OOPSLA 2024
A Constraint Solving Approach to Parikh Images of Regular Languages
OOPSLA 2024
AdoB: Bridging Benign and Byzantine Consensus with Atomic Distributed Objects
OOPSLA 2024
A Learning-Based Approach to Static Program Slicing
OOPSLA 2024
Pre-print
A Pure Demand Operational Semantics with Applications to Program Analysis
OOPSLA 2024
DOI Pre-print
Cedar: A New Language for Expressive, Fast, Safe, and Analyzable Authorization
OOPSLA 2024
Cocoon: Static Information Flow Control in Rust
OOPSLA 2024
Compiling Recurrences over Dense and Sparse Arrays
OOPSLA 2024
CYCLE: Learning to Self-Refine the Code Generation
OOPSLA 2024
Degrees of Separation: A Flexible Type System for Safe Concurrency
OOPSLA 2024
Deriving Dependently-Typed OOP from First Principles
OOPSLA 2024
Design and Implementation of an Aspect-Oriented C Programming Language
OOPSLA 2024
Distributions for Compositionally Differentiating Parametric Discontinuities
OOPSLA 2024
Enhancing Static Analysis for Practical Bug Detection: An LLM-Integrated Approach
OOPSLA 2024
Evaluating the effectiveness of Deep Learning Models for Foundational Program Analysis Tasks
OOPSLA 2024
Exact Bayesian Inference for Loopy Probabilistic Programs Using Generating Functions
OOPSLA 2024
Finding Cross-rule Optimization Bugs in Datalog Engines
OOPSLA 2024
Forge: A Tool and Language for Teaching Formal Methods
OOPSLA 2024
Fulfilling OCaml modules with transparency
OOPSLA 2024
Functional Ownership through Fractional Uniqueness
OOPSLA 2024
Gradually Typed Languages Should Be Vigilant!
OOPSLA 2024
HOL4P4: mechanized small-step semantics for P4
OOPSLA 2024
Hopping Proofs of Expectation-Based Properties: Applications to Skiplists and Security Proofs
OOPSLA 2024
Hydra: Generalizing Peephole Optimizations with Program Synthesis
OOPSLA 2024
Pre-print
Identifying and Correcting Programming Language Behavior Misconceptions
OOPSLA 2024
Inductive diagrams for causal reasoning
OOPSLA 2024
Pre-print
Iterative-Epoch Online Cycle Elimination for Context-Free Language Reachability
OOPSLA 2024
Learning Abstraction Selection for Bayesian Program Analysis
OOPSLA 2024
DOI Pre-print
Mechanizing the CMP Abstraction for Parameterized Verification
OOPSLA 2024
Message-Observing Sessions
OOPSLA 2024
Modeling Dynamic (De)Allocations of Local Memory for Translation Validation
OOPSLA 2024
Multiverse Notebook: Shifting Data Scientists to Time Travelers
OOPSLA 2024
DOI
Newtonian Program Analysis of Probabilistic Programs
OOPSLA 2024
Outcome Separation Logic: Local Reasoning for Correctness and Incorrectness with Computational Effects
OOPSLA 2024
ParDiff: Practical Static Differential Analysis of Network Protocol Parsers
OOPSLA 2024
Persimmon: Nested Family Polymorphism with Extensible Variant Types
OOPSLA 2024
PP-CSA: Practical Privacy-Preserving Software Call Stack Analysis
OOPSLA 2024
Profiling Programming Language Learning
OOPSLA 2024
PROMPT: A Fast and Extensible Memory Profiling Framework
OOPSLA 2024
PyDex: Repairing Bugs in Introductory Python Assignments using LLMs
OOPSLA 2024
Qualifying System F-sub
OOPSLA 2024
Quantitative Bounds on Resource Usage of Probabilistic Programs
OOPSLA 2024
Quantum Control Machine: The Limits of Control Flow in Quantum Programming
OOPSLA 2024
Quarl: A Learning-Based Quantum Circuit Optimizer
OOPSLA 2024
Scenario-based Proofs for Concurrent Objects
OOPSLA 2024
Seneca: Taint-Based Call Graph Construction for Java Object Deserialization
OOPSLA 2024
Synthetiq: Fast and Versatile Quantum Circuit Synthesis
OOPSLA 2024
Taypsi: Static Enforcement of Privacy Policies for Policy-Agnostic Oblivious Computation
OOPSLA 2024
TorchQL: A Programming Framework for Integrity Constraints in Machine Learning
OOPSLA 2024
Understanding and Finding Java Decompiler Bugs
OOPSLA 2024
UniSparse: An Intermediate Language for General Sparse Format Customization
OOPSLA 2024
VeriEQL: Bounded Equivalence Verification for Complex SQL Queries with Integrity Constraints
OOPSLA 2024
Pre-print
Verification of Neural Networks' Global Robustness
OOPSLA 2024

Call for Papers

The OOPSLA issue of the Proceedings of the ACM on Programming Languages (PACMPL) welcomes papers focusing on all practical and theoretical investigations of programming languages, systems and environments. Papers may target any stage of software development, including requirements, modelling, prototyping, design, implementation, generation, analysis, verification, testing, evaluation, maintenance, and reuse of software systems. Contributions may include the development of new tools, techniques, principles, and evaluations.

OOPSLA 2024 will have two separate rounds of reviewing, with the Round 1 submission deadline on the 20th of October 2023 (note that SPLASH/OOPSLA 2023 is 22-27 October 2023) and the Round 2 submission deadline on the 5th of April 2024 (Anywhere on Earth).

In each round, papers will have a final outcome of Accept, Revise, or Reject—see Review Process for details. Papers accepted at either of the rounds will be published in the 2023 volume of PACMPL(OOPSLA) and invited to be presented at the SPLASH conference in October 2024.

Review Process

PACMPL(OOPSLA) has two rounds of reviewing with submission deadlines around October and April each year. As you submit your paper you will receive around three reviews and an opportunity to provide an author response that will be read and addressed by the reviewers in the final decision outcome summary. There are 5 possible outcomes at the end of the round:

Accept: Your paper will appear in the upcoming volume of PACMPL(OOPSLA).

Conditional Accept: You will receive a list of required revisions that you will need to address. You must submit a revised paper, a clear explanation of how your revision addresses these comments, and — if possible — a diff of the PDF as supplementary material. Assuming you meet the listed requirements, after further review by the same reviewers, your paper will very likely be accepted. This process has to be completed within two months of the initial decision for the paper to be accepted, so we encourage timely turnaround in case revisions take more than one cycle to be accepted. Please note that when resubmitting the paper for a conditional accept review it should remain anonymous until fully accepted.

Minor Revision: The reviewers have concerns that go beyond what can be enumerated in a list. Therefore, while you may receive a list of revisions suggested by the reviewers, this will not necessarily be comprehensive. You will have the opportunity to resubmit your revised paper and have it re-reviewed by the same reviewers, which may or may not result in your paper’s acceptance. When you resubmit, you should clearly explain how the revisions address the comments of the reviewers, by including a document describing the changes and — if possible — a diff of the PDF as supplementary material. This process has to be completed within two months of the initial decision for the paper to be accepted in the current round, so we encourage timely turnaround in case revisions take more than one cycle to be accepted. Please note that when resubmitting the paper for a minor revision review it should remain anonymous until fully accepted.

Major Revision: You will receive a list of revisions suggested by the reviewers. Papers in this category are invited to submit a revision to the next round of submissions with a specific set of expectations to be met. When you resubmit, you should clearly explain how the revisions address the comments of the reviewers, by including a document describing the changes and — if possible — a diff of the PDF as supplementary material. The revised paper will be re-evaluated in the next round. Resubmitted papers will retain the same reviewers throughout the process to the extent possible. Please note that when resubmitting the paper for a major revision review in the next round it should remain anonymous.

Reject: Rejected papers will not be included in the upcoming volume of PACMPL(OOPSLA). Papers in this category are not guaranteed a review if resubmitted less than one year from the date of the original submission. A paper will be judged to be a resubmission if it is substantially similar to the original submission. The Chairs will decide whether or not a paper is a resubmission of the same work.

Submissions

Submitted papers (including resubmissions) must be at most 23 pages using the template below. The references do not count towards this limit. No appendices are allowed on the main paper, instead, authors can upload supplementary material with no page or content restrictions, but reviewers may choose to ignore it. The PACMPL templates used for SPLASH (Microsoft Word and LaTeX) and the instructions for their use can be found on the SIGPLAN author information page and the ACM Primary Article Template pages.

As of late 2023, the ACM LaTeX Template was located here with the relevant file in the samples folder and called sample-acmsmall.tex .

Papers may use either numeric or author-year citations. In LaTeX, use \citestyle{acmauthoryear} to select author-year citations; nothing needs to be done to use numeric citations, which are the default.

PACMPL uses double-blind reviewing. Authors’ identities are only revealed if a paper is accepted. Papers must

  • omit author names and institutions,
  • use the third person when referencing your work,
  • anonymise supplementary material.

Nothing should be done in the name of anonymity that weakens the submission; see the DBR FAQ. When in doubt, contact the Review Committee Chairs.

Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy. Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism. Submissions are expected to comply with the ACM Policies for Authorship.

Artifacts

Authors should indicate with their initial submission if an artifact exists, describe its nature and limitations, and indicate if it will be submitted for evaluation. Accepted papers that fail to provide an artifact will be requested to explain the reason they cannot support replication. It is understood that some papers have no artifacts. Please note that the artifact submission deadline will be following closely the paper notification deadline so make sure you check the Artifact Call as soon as you submit your paper to PACMPL(OOPSLA).

Data-Availability Statement

To help readers find data and software, OOPSLA recommends adding a section just before the references titled Data-Availability Statement. If the paper has an artifact, cite it here. If there is no artifact, this section can explain how to obtain relevant code. The statement does not count toward the OOPSLA 2023 page limit. It may be included in the submitted paper; in fact we encourage this, even if the DOI is not ready yet.

Example:
\section{Conclusion}
....

\section*{Data-Availability Statement}
The software that supports~\cref{s:design,s:evaluation}
is available on Software Heritage~\cite{artifact-swh}
and Zenodo~\cite{artifact-doi}.

\begin{acks}
....

Expert PC Members

During the submission, we will ask you to list up to 3 non-conflicted PC members who you think are experts on the topic of this submission, starting with the most expert. This list will not be used as an input during the paper assignment and it will not be visible to the PC. It may be used by the PC Chair and Associate Chairs for advice on external experts if the paper lacks expert reviews.

Publication

PACMPL is a Gold Open Access journal, all papers will be freely available to the public. Authors can voluntarily cover the article processing charge ($400 USD), but payment is not required. The official publication date is the date the journal is made available in the ACM Digital Library.

The journal issue and associated papers accepted in Round 1 (OOPSLA1) will be published no earlier than the 1st of April 2024, while those accepted in Round 2 (OOPSLA2) will be published no earlier than the 1st of October 2024. The official publication date affects the deadline for any patent filings related to published work.

By submitting your article to an ACM Publication, you are acknowledging that you and your co-authors are subject to all ACM Publications Policies, including ACM’s new Publications Policy on Research Involving Human Participants and Subjects. Alleged violations of this policy or any ACM Publications Policy will be investigated by ACM and may result in a full retraction of your paper, in addition to other potential penalties, as per ACM Publications Policy.

Please ensure that you and your co-authors obtain an ORCID ID, so you can complete the publishing process for your accepted paper. ACM has been involved in ORCID from the start and we have recently made a commitment to collect ORCID IDs from all of our published authors. We are committed to improving author discoverability, ensuring proper attribution and contributing to ongoing community efforts around name normalization; your ORCID ID will help in these efforts.

The ACM Publications Board has recently updated the ACM Authorship Policy in several ways:

  • Addressing the use of generative AI systems in the publications process
  • Clarifying criteria for authorship and the responsibilities of authors
  • Defining prohibited behaviour, such as gift, ghost, or purchased authorship
  • Providing a linked FAQ explaining the rationale for the policy and providing additional details

You can find the updated policy here:

https://www.acm.org/publications/policies/new-acm-policy-on-authorship

Camera Ready Requirements

The page limit for the camera-ready version is 27 pages plus references (note the 4-page increase compared to the reviewed version to accommodate any further changes requested by the reviewers), there are no page charges for this extension to 27 pages excluding references.

FAQ

Selection Criteria

We consider the following criteria when evaluating papers:

Novelty: The paper presents new ideas and results and places them appropriately within the context established by previous research.

Importance: The paper contributes to the advancement of knowledge in the field. We also welcome papers that diverge from the dominant trajectory of the field.

Evidence: The paper presents sufficient evidence supporting its claims, such as proofs, implemented systems, experimental results, statistical analyses, case studies, and anecdotes.

Clarity: The paper presents its contributions, methodology and results clearly.

Papers Resubmitted from previous year OOPSLA R2 to this year OOPSLA R1

Q: What process is followed for “major revisions” papers between different years? We follow the same timeline as the other papers with the following two differences: (1) we assign the same reviewers you had in the previous year’s OOPSLA; (2) getting another “major revision” is not an option given to the reviewers.

Artifacts

Q: Are artifacts required? No! It is understood that some papers have no artifacts. But if an artifact is not provided when the claims in the paper refer to an artifact, the authors must explain why their work is not available for repetition.

Q: Can a paper be accepted if the artifact is rejected? Yes! The reasons for rejecting an artifact are multiple and often stem from the quality of the packaging.

Double-Blinding Submissions (Authors)

Q: What exactly do I have to do to anonymize my paper? Use common sense. Your job is not to make your identity undiscoverable but simply to make it possible for reviewers to evaluate your submission without having to know who you are. The specific guidelines stated in the call for papers are simple: omit authors’ names from your title page, and when you cite your own work, refer to it in the third person. For example, if your name is Smith and you have worked on amphibious type systems, instead of saying “We extend our earlier work on statically typed toads [Smith 2004],” you might say “We extend Smith’s [2004] earlier work on statically typed toads.” Also, be sure not to include any acknowledgements that would give away your identity.

Q: Should I change the name of my system? No.

Q: My submission is based on code available in a public repository. How do I deal with this? Cite the code in your paper, but remove the URL and, instead say “link to repository removed for double-blind review”. If you believe reviewer access to your code would help during author response, contact the Review Committee Chairs.

Q: I am submitting an extension of my workshop paper, should I anonymize reference to that work? No. But we recommend you do not use the same title so that it clearly distinguishes the papers.

Q: Am I allowed to post my paper on my web page or arXiv? send it to colleagues? give a talk about it? on social media? We have developed guidelines to help navigate the tension between the normal communication of scientific results and actions that essentially force potential reviewers to learn the identity of authors. Roughly speaking, you may discuss work under submission, but you should not broadly advertise your work through media that are likely to reach your reviewers. We acknowledge there are grey areas and trade-offs.

Things you may do:

  • Put your submission on your home page.
  • Discuss your work with anyone not on the review committees or reviewers with whom you already have a conflict.
  • Present your work at professional meetings, job interviews, etc.
  • Submit work previously discussed at an informal workshop, previously posted on arXiv or a similar site, previously submitted to a conference not using double-blind reviewing, etc.

Things you should not do:

  • Contact members of the review committee about your work, or deliberately present your work where you expect them to be.
  • Publicize your work on social media if wide public [re-]propagation is common (e.g., Twitter) and therefore likely to reach potential reviewers. For example, on Facebook, a post with a broad privacy setting (public or all friends) saying, “Whew, OOPSLA paper in, time to sleep” is okay, but one describing the work or giving its title is not appropriate. Alternatively, a post to a group including only the colleagues at your institution is fine.
  • Reviewers will not be asked to recuse themselves from reviewing your paper unless they feel you have gone out of your way to advertise your authorship information to them. If you are unsure about what constitutes “going out of your way”, please contact the Review Committee Chairs.