Welcome to the website of The 20th Asian Symposium on Programming Languages and Systems (APLAS). APLAS aims to stimulate programming language research by providing a forum for the presentation of latest results and the exchange of ideas in programming languages and systems. APLAS is based in Asia but is an international forum that serves the worldwide programming languages community. APLAS 2022 will be co-located with SPLASH 2022.

APLAS’22 Proceedings can be downloaded free of charge before December 31, 2022.

The 20th Asian Symposium on Programming Languages and Systems: Call for Papers

View track page for all details

We solicit submissions in the form of regular research papers describing original scientific research results, including system development and case studies. Among others, solicited topics include:

• programming paradigms and styles: functional programming; object-oriented programming; probabilistic programming; logic programming; constraint programming; extensible programming languages; programming languages for systems code; novel programming paradigms;
• methods and tools to specify and reason about programs and languages: programming techniques; meta-programming; domain-specific languages; proof assistants; type systems; dependent types; program logics, static and dynamic program analysis; language-based security; model checking; testing;
• programming language foundations: formal semantics; type theory; logical foundations; category theory; automata; effects; monads and comonads; recursion and corecursion; continuations and effect handlers; program verification; memory models; abstract interpretation;
• methods and tools for implementation: compilers; program transformations; rewriting systems; partial evaluation; virtual machines; refactoring; intermediate languages; run-time environments; garbage collection and memory management; tracing; profiling; build systems; program synthesis;
• concurrency and distribution: process algebras; concurrency theory; session types; parallel programming; service-oriented computing; distributed and mobile computing; actor-based languages; verification and testing of concurrent and distributed systems;
• applications and emerging topics: programming languages and PL methods in education, security, privacy, database systems, computational biology, signal processing, graphics, human-computer interaction, computer-aided design, artificial intelligence and machine learning; case studies in program analysis and verification.

General Information

Submissions should not exceed 17 pages, excluding bibliography in the Springer LNCS format (LaTeX template is available at this page under “Templates, sample files & useful links”). The accepted papers will be allowed to use one extra page for the content to accommodate feedback from the reviews in the final paper versions.

Submit your paper via this HotCRP page.

The review process of APLAS 2022 is double-anonymous, with a rebuttal phase. In your submission, please, omit your names and institutions; refer to your prior work in the third person, just as you refer to prior work by others; do not include acknowledgements that might identify you.

Additional material intended for reviewers but not for publication in the final version - for example, details of proofs - may be placed in a clearly marked appendix that is not included in the page limit. Reviewers are at liberty to ignore appendices and papers must be understandable without them.

APLAS Research Artifacts: Call for Artifacts

View track page for all details

APLAS 2022 will have post-paper-acceptance voluntary artifact evaluation (new in 2022!). Authors of accepted will be welcome to submit artifacts for evaluation after paper notification. The outcome will not alter the paper acceptance decision.

We will publish the submission links once authors of accepted papers have been notified of acceptance.

Submission 

Please submit your artifact via HotCRP:  

https://aplas22ae.hotcrp.com/

General Information 

Research artifacts are not just about presenting raw code and raw data.  The artifact evaluation process is there to aid in reproducible research, and research output conservancy.  A well-packaged artifact is key to ensuring the longevity and use of your work for decades to come.  Thus, you should think of the readers of the packaged artifact as a history buff on a curated tour in a museum, rather than an archaeologist in the middle of a dig searching for answers.  

It belongs in a Virtual Machine (or Container)! 

We strongly advise packaging your artifact in a virtual machine, or container, that runs out of the box with very little system-specific configuration. 

We encourage all authors to include provide a working installation of their artifact, together with the source and build scripts to facilitate regeneration of the artifact. 

Provisioning pre-built virtual machines, and containers, is preferable to providing tooling to build them, as this alleviates reliance on external dependencies.   

For some submissions, for example FPGA related research, provisioning access to the hardware itself is not possible. 

We thus advise the authors to think about how their work can be made accessible to reviewers, and potentially what (if any) of the work can be bundled in a Virtual Machine or Container to demonstrate their research’s results. 

Artifact evaluation is private 

Submission of an artifact does not imply automatic permission to make its content public. 

AEC members will be instructed that they may not publicize any part of the submitted artifacts during or after completing evaluation, and they will not retain any part of any artifact after evaluation.  Thus, you are free to include models, data files, proprietary binaries, and similar items in your artifact. 

Artifact evaluation is single-blind. 

Please take precautions (e.g. turning off analytics, logging) to help prevent accidentally learning the identities of reviewers. 

Submission Requirements 

Your submission to HotCRP should consist of three things: 

1. The latest version (ideally camera-ready version) of your accepted paper (in pdf format). 
2. A README.md file that explains your artifact (details below). 
3. A Zenodo link (details below).  

We detail the packaging requirements of the artifact in the next section. 

README.md  

The README.md file is there to provide reviewers with salient information about the artifact for use during the review process.   

Specifically, the README.md file should detail: 

1. the artifact itself, providing salient information about what is being submitted and how it relates to the submitted paper; and 
2. the size of the artifact.   

Zenodo Link 

Please create a Zenodo (https://zenodo.org/) repository.  If you intend to publish the artifact, you can choose Open Access for License.  Please note that this would generate a Zenodo DOI that is permanently public.  On the other hand, you can create a “private” repository by checking Restricted Access which would require you to grant permission to someone (in our case, the AEC members) who wanted to access the repository.   

Packaging Requirements 

  To ensure consistency for the AEC Members we require all artifacts to adhere to the following requirements.  

1. The ‘artifact’ must be submitted as a single archive in a known open format. 
2. The intended audience of the artifact is an interested researcher from the future, not the reviewers themselves. 
3. The artifact must contain: 

• A README.md file that provides: information About the Archive;  a Link to Research Paper section;  a Getting Started Guide; and Step-by-Step Instructions that connects your submitted artifact to the submitted research paper. 
• the artifact itself, guidance over packaging can be found in the next section; 
• copies of any source code contained within the artifact.   

About the Archive 

The README.md will be one of the first parts of the artifact that the reader encounters. 

Please use this space to provide salient information about what is being submitted and how it relates to the submitted paper, and what the reader is to expect from interacting with the artifact, and how best the reader can interact with the artifact. 

Moreover, alongside detailing the minimum software requirements required to interact with the contained artifact, and what (if any) external dependencies the artifact relays upon, an explicit manifest of what other useful software the container/virtual machine has that the user may require, for example which editor support is there would be useful.   

Link to Research Paper  

The Link to Research Paper section will detail how the research artifact links to the research paper. 

Explicitly it should list: 

• Claims from the paper supported by the artifact, and how/why. 
• Claims from the paper not supported by the artifact, and how/why.  

Example: Performance claims cannot be reproduced in VM, authors are not allowed to redistribute specific benchmarks, etc. Artifact reviewers can then center their reviews / evaluation around these specific claims. 

Getting Started Guide 

The Getting Started Guide should contain setup instructions (including, for example, a pointer to the VM player software, its version, passwords if needed, etc.) and basic testing of your artifact that you expect a reviewer to be able to complete in 30 minutes. 

Reviewers will follow all the steps in the guide during an initial kick-the-tires phase. 

The Getting Started Guide should be as simple as possible, and yet it should stress the key elements of your artifact. Anyone who has followed the Getting Started Guide should have no technical difficulties with the rest of your artifact.   

Step-By-Step Instructions 

The Step-by-Step Instructions explain how to reproduce any experiments or other activities that support the conclusions in your paper. Write this for readers who have a deep interest in your work and are studying it to improve it or compare against it. If your artifact runs for more than a few minutes, point this out and explain how to run it on smaller inputs.  

Where appropriate, include descriptions of and links to files (included in the archive) that represent expected outputs (e.g. the log files expected to be generated by your tool on the given inputs); if there are warnings that are safe to be ignored, explain which ones they are. 

Why Copies of the submitted code?  

We require copies of source code/documentation alongside the artifact as sometimes a container does not contain the most optimal way to view the source code.  Think of it as the provided source code is the sheet music and the container is a recording of it in action 

Containing the Artifact 

   When packaging your artifact, please keep in mind: a) how accessible you are making your artifact to other researchers, and b) the fact that the AEC members will have a limited time in which to make an assessment of each artifact. 

Your artifact should have a container or a bootable virtual machine image with all of the necessary libraries installed.  

We strongly recommend use of the following technologies to contain the artifact: 

1. Docker (https://www.docker.com) 
2. VirtualBox (https://www.virtualbox.org) 

Other technologies that authors may find helpful are: 

1. Packer (https://www.packer.io) for scripting, and staging, container/virtual machine creation.  

Using a container or a virtual machine image provides a way to make an easily reproducible environment — it is less susceptible to bit rot.  It also helps the AEC have confidence that errors or other problems cannot cause harm to their machines. 

It would also be prudent to be mindful of the final size of the resulting container/virtual machine.  Anything greater than 1 GB in size can be a hefty download for those not on University networks.  There are small, more lightweight, Linux Distributions that can help reduce the virtual machine/container size to a couple hundred megabytes rather than several gigabytes.  One can also strip the virtual machine of unnecessary software. There are guides out there for how to do this. Moreover, is a full GUI necessary or is a purely TUI good enough for submission?

We stress that authors should consider how they can reduce the size of your artifact to only the necessary components. 

You should upload your artifact to Zenodo and submit the Zenodo link. Please use open formats for documents. 

Discussion with Reviewers 

We expect each artifact to receive 3-4 reviews. 

Throughout the review period, reviews will be submitted to HotCRP and will be (approximately) continuously visible to authors.  AEC reviewers will be able to continuously interact (anonymously) with authors for clarifications, system-specific patches, and other logistics to help ensure that the artifact can be evaluated.  The goal of continuous interaction is to prevent rejecting artifacts for a “wrong library version” types of problems. 

Distinguished Artifacts 

Based on the reviews and discussion among the AEC, one or more artifacts will be selected for Distinguished Artifact awards.