PACMPL (ICFP) seeks contributions on the design, implementations, principles, and uses of functional programming, covering the entire spectrum of work, from practice to theory, including its peripheries. Authors of papers published in this issue of PACMPL will present their work at ICFP in Jersey City, providing an opportunity for researchers and developers to hear about the latest work in functional programming.

PACMPL Volume 4, Issue ICFP, August 2020 is now available Gold Open Access from the ACM Digital Library.

During the conference, the ICFP technical program will run twice—a first time starting at 9AM in New York and then a second time 12 hours later, starting at 9AM (the next day) in Beijing. To make this work, all authors have pre-recorded their talks and will participate in text-based discussion during and in live video discussion after one or both “showings” of their paper. The text chat will persist across mirrors and the video Q&A track will allow interested colleagues to get into a deep discussion right away. The videos will be freely available through a youtube livestream, but only registered ICFP participants will be able to access the text and video discussions.

The schedule of talks and live Q&A sessions is available in the conference program.

Accepted Papers

Call for Papers

Executive Summary of Changes from Previous Year

The option to attach reviews from prior submissions has been removed, as no authors took advantage of it in 2019, and thus we prefer to avoid cluttering submission forms with the associated fields. There are no other process changes beyond setting 2020-specific dates.

Scope

PACMPL issue ICFP 2020 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to):

• Language Design: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; macros; pattern matching; type systems; type inference; dependent types; session types; gradual typing; refinement types; interoperability; domain-specific languages; imperative programming; object-oriented programming; logic programming; probabilistic programming; reactive programming; generic programming; bidirectional programming.
• Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; runtime systems; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources.
• Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling; build systems; program synthesis.
• Foundations: formal semantics; lambda calculus; program equivalence; rewriting; type theory; logic; category theory; monads; continuations; control; state; effects; names and binding; program verification.
• Analysis and Transformation: control flow; data flow; abstract interpretation; partial evaluation; program calculation.
• Applications: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; graphics and multimedia; GPU programming; scripting; system administration; security.
• Education: teaching introductory programming; parallel programming; mathematical proof; algebra.

Submissions will be evaluated according to their relevance, correctness, significance, originality, and clarity. Each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience.

PACMPL issue ICFP 2020 also welcomes submissions in two separate categories — Functional Pearls and Experience Reports — that must be marked as such when submitted and that need not report original research results. Detailed guidelines on both categories are given at the end of this call.

Please contact the principal editor if you have questions or are concerned about the appropriateness of a topic.

Preparation of Submissions

Deadline: The deadline for submissions is Tuesday, March 3, 2020, Anywhere on Earth. This deadline will be enforced strictly.

Formatting: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the “ACM Small” template that is available in both LaTeX and Word formats. For authors using LaTeX, a lighter-weight package, including only the essential files, is also available.

There is a limit of 25 pages for a full paper or Functional Pearl and 12 pages for an Experience Report; in either case, the bibliography will not be counted against these limits. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting will be rejected summarily. Supplementary material can and should be separately submitted (see below).

See also PACMPL’s Information and Guidelines for Authors.

Submission: Submissions will be accepted via the ICFP 2020 HotCRP instance.

Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface.

Author Response Period: Authors will have a 72-hour period, starting at 14:00 UTC on Tuesday, April 21, 2020, to read reviews and respond to them.

Supplementary Material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball.

Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. The intent is to create a level playing field for all materials consulted in evaluating a submission, so reviewers will be directed not to consult URL-linked materials, which may have been updated since the deadline.

Authors are free to upload both anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material for a paper will be revealed a reviewer only after submission of a review, at which time author identity is revealed.

Authorship Policies: All submissions are expected to comply with the ACM Policies for Authorship.

Republication Policies: Each submission must adhere to SIGPLAN’s republication policy.

Review Process

This section outlines the two-stage process with lightweight-double-blind reviewing that will be used to select papers for PACMPL issue ICFP 2020. We anticipate that there will be a need to clarify and expand on this process, and as a starting point we mention the ICFP 2019 Submission and Reviewing FAQ.

PACMPL issue ICFP 2020 will employ a two-stage review process. The first stage in the review process will assess submitted papers using the criteria stated above and will allow for feedback and input on initial reviews through the author response period mentioned previously. Through an online discussion process, a set of papers will be accepted conditionally, and all other papers will be rejected. Authors will be notified of these decisions on May 8, 2020.

Authors of conditionally accepted papers will be provided with committee reviews (just as in previous conferences) along with a set of mandatory revisions. After four weeks (June 5, 2020), the authors will provide a second submission. The second and final reviewing phase assesses whether the mandatory revisions have been addressed adequately by the authors and thereby determines the final accept/reject status of the paper. The intent and expectation is that the mandatory revisions can be addressed within four weeks and hence that conditionally accepted papers will in general be accepted in the second phase.

The second submission should clearly identify how the mandatory revisions were addressed. To that end, the second submission must be accompanied by a cover letter mapping each mandatory revision request to specific parts of the paper. The cover letter will facilitate a quick second review, allowing for confirmation of final acceptance within two weeks. Conversely, the absence of a cover letter will be grounds for the paper’s rejection.

PACMPL issue ICFP 2020 will employ a lightweight-double-blind reviewing process. To that end, submitted papers must adhere to two rules:

1. author names and institutions must be omitted, and
2. references to authors’ own related work should be in the third person (e.g., not “we build on our previous work…” but rather “we build on the work of…”).

The purpose of this process is to help the reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their papers as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas.

Information for Authors of Accepted Papers

• PACMPL provides extensive information on copyright transfer and other important logistics. Like other participating conferences, ICFP follows these rules directly. Among other important elements, please note that there is an open-access fee associated with publication, but SIGPLAN is able to pay it in cases where authors’ institutions are not.

• As a condition of acceptance, final versions of all papers must adhere to the new ACM Small format. The page limit for the final versions of papers will be increased by two pages to help authors respond to reviewer comments and mandatory revisions: 27 pages plus bibliography for a regular paper or Functional Pearl, 14 pages plus bibliography for an Experience Report. Also, one notable formatting convention of PACMPL is that, when appendices are included in the main paper rather than in separate online supplements, appendices should appear before references.

• The official publication date is the date the papers are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work.

• At least one author of each accepted submission will be expected to attend and present that paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. Presentations will be videotaped and released online if the presenter consents.

  • In extraordinary circumstances, at the discretion of the principal editor, alternative presentation methods may be approved for specific papers. The canonical example is where all authors are denied visas to the ICFP host country, in which case a nonauthor may be deputized to present, or various electronic substitutes may be considered. We list these options in the interest of transparency, but please keep in mind that, most years, no exceptions are granted. This option is not meant, e.g., to excuse cases where authors find themselves double-booked with other meetings (so, at the time of submitting a paper, please do keep the days of the conference reserved on at least one author’s calendar).

Artifact Evaluation

Authors of papers that are accepted conditionally in the first phase of the review process will be encouraged (but not required) to submit supporting materials for Artifact Evaluation. These items will then be reviewed by an Artifact Evaluation Committee, separate from the paper Review Committee, whose task is to assess how the artifacts support the work described in the associated paper. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers will be encouraged to make the supporting materials publicly available upon publication of the papers, for example, by including them as “source materials” in the ACM Digital Library. An additional seal will mark papers whose artifacts are made available, as outlined in the ACM guidelines for artifact badging.

Participation in Artifact Evaluation is voluntary and will not influence the final decision regarding paper acceptance.

Special Categories of Papers

In addition to research papers, PACMPL issue ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers; and Experience Reports, which are limited to half the length of a full paper. Authors submitting such papers should consider the following guidelines.

Functional Pearls

A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to:

• a new and thought-provoking way of looking at an old idea
• an instructive example of program calculation or proof
• a nifty presentation of an old or new data structure
• an interesting application of functional-programming techniques
• a novel use or exposition of functional programming in the classroom

While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls.

Functional Pearls are valued as highly and judged as rigorously as ordinary papers but using somewhat different criteria. In particular, a pearl is not required to report original research, but it should be concise, instructive, and entertaining. A pearl is likely to be rejected if its readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing.

A submission that is intended to be treated as a pearl must be marked as such on the submission web page and should contain the words “Functional Pearl” somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference’s acceptance rate.

Experience Reports

The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works — or to describe what obstacles prevent it from working.

Possible topics for an Experience Report include but are not limited to:

• insights gained from real-world projects using functional programming
• comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum
• project-management, business, or legal issues encountered when using functional programming in a real-world project
• curricular issues encountered when using functional programming in education
• real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general

An Experience Report is distinguished from a normal PACMPL issue ICFP paper by its title, by its length, and by the criteria used to evaluate it.

Both in the papers and in any citations, the title of each accepted Experience Report must end with the words “(Experience Report)” in parentheses. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers.

Experience Report submissions can be at most 12 pages long, excluding bibliography.

Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience Reports may be asked to give shorter talks.

Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel.

The review committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well-argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers that show how functional programming was used than from papers that only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person’s experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people.

An Experience Report should be short and to the point: it should make a claim about how well functional programming worked on a particular project and why, and it should produce evidence to substantiate this claim. If functional programming worked in this case in the same ways it has worked for others, the paper need only summarize the results — the main part of the paper should discuss how well it worked and in what context. Most readers will not want to know all the details of the project and its implementation, but the paper should characterize the project and its context well enough so that readers can judge to what degree this experience is relevant to their own projects. The paper should take care to highlight any unusual aspects of the project. Specifics about the project are more valuable than generalities about functional programming; for example, it is more valuable to say that the team delivered its software a month ahead of schedule than it is to say that functional programming made the team more productive.

If the paper not only describes experience but also presents new technical results, or if the experience refutes cherished beliefs of the functional-programming community, it may be better to submit it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. The principal editor will be happy to advise on any concerns about which category to submit to.

Very similarly to how PLDI 2020 worked, this ICFP will present papers’ talks via prerecorded videos with live Q&A. Some of the technical details are not yet finalized (for instance, we will collect information on speaker availability, to guide scheduling), but here is what we hope is enough information for authors to complete their videos comfortably. (And thanks to the PLDI organizers for creating their page, our very direct inspiration for this one!)

Authors are required to submit one video per paper:

• Due August 8 2020: A paper presentation video of up to 14.5 minutes in length that will be broadcast during the conference.
• File format: MP4
• Aspect ratio: 16:9
• Other elements, like bitrate and screen layout (where image of the speaker appears, etc.): left up to authors

To retain some of the personal vibe that one gets at a physical conference, we encourage authors to feature some amount of footage of themselves presenting in their videos, rather than simply showing slides with a voice-over. As a rough orientation on how large video files should be, we suggest 50 MB. Much larger indicates you’ve probably used an unproductively high bitrate, and much smaller indicates the quality probably isn’t sufficient.

There are many viable ways to record a video. Here are some resources on the topic that we have gathered from the community:

• In the PLDI experience, one of the biggest recurring issues was sound quality. Authors own a wide array of different sound-recording devices, some of which produce audio that stands out as distractingly unclear. We recommend that every presenter invest in a good headset with microphone, and, if videos with poor-quality audio are uploaded, we may get back to the authors asking that they record again with better microphones.

• The ASPLOS 2020 conference recently ran successfully in a virtual fashion. Check out the ASPLOS 2020 YouTube channel for many examples of presentations.

• This Remote Video Presentation Guide from SIGCHI provides useful advice.

• Here’s another guide from DebConf.

• ACM recently set up a Presidential Task Force on virtual conferences. Section 3.2 of their draft report has guidelines on the equipment that remote attendees will need, including advice on how to set up good lighting conditions.

• Open Broadcaster Software provides free and open-source solutions for video recording.

• Zoom provides a simple and low-overhead method for recording.

• PowerPoint provides a mechanism for recording slides, and it is likely that other similar packages also provide such facilities.

Please contact the program chair, Adam Chlipala, if you have further suggestions of resources that could be added to this page.