ICFP 2018 - Research Papers - ICFP 2018 (original) (raw)

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 St. Louis, providing an opportunity for researchers and developers to hear about the latest work in functional programming.

The program is currently displayed in (GMT-05:00) Cancun.

Use conference time zone: (GMT-05:00) CancunSelect other time zone

The GMT offsets shown reflect the offsets at the moment of the conference.

By setting a time band, the program will dim events that are outside this time window. This is useful for (virtual) conferences with a continuous program (with repeated sessions).
The time band will also limit the events that are included in the personal iCalendar subscription service.

Display full programSpecify a time band

-

You're viewing the program in a time zone which is different from your device's time zone change time zone

10:30 - 12:00 Environments and ToolsResearch Papers at Stifel Theatre Chair(s): Alejandro Russo Chalmers University of Technology, Sweden
10:3022mTalk **Build Systems à la CarteDistinguished Paper**Research PapersAndrey Mokhov Newcastle University, UK, Neil Mitchell , Simon Peyton Jones Microsoft, UK DOI
10:5222mTalk **Keep Your Laziness in Check**Research PapersKenneth Foner , Hengchu Zhang University of Pennsylvania, Leonidas Lampropoulos University of Pennsylvania DOI
11:1522mTalk **Merlin: A Language Server for OCaml (Experience Report)**Research PapersFrédéric Bour Facebook Paris, Thomas Réfis , Gabriel Scherer INRIA Saclay DOI
11:3722mTalk **Functional Programming for Compiling and Decompiling Computer-Aided Design**Research PapersChandrakana Nandi University of Washington, USA, James R. Wilcox University of Washington, Taylor Blau University of Washington, Dan Grossman University of Washington, Zachary Tatlock University of Washington, Seattle DOI
13:00 - 14:30 Program ConstructionResearch Papers at Stifel Theatre Chair(s): J. Garrett Morris University of Kansas, USA
13:0022mTalk **Prototyping a Functional Language using Higher-Order Logic Programming: A Functional Pearl on Learning the Ways of λProlog/Makam**Research PapersAntonis Stampoulis Originate Inc., Adam Chlipala Massachusetts Institute of Technology, USA DOI
13:2222mTalk **A Type and Scope Safe Universe of Syntaxes with Binding: Their Semantics and Proofs**Research PapersGuillaume Allais Radboud University Nijmegen, Robert Atkey University of Strathclyde, James Chapman , Conor McBride , James McKinna DOI
13:4522mTalk **Reasonably Programmable Literal Notation**Research PapersCyrus Omar University of Chicago, Jonathan Aldrich Carnegie Mellon University Link to publication DOI
14:0722mTalk **Refunctionalization of Abstract Abstract Machines: Bridging the Gap between Abstract Abstract Machines and Abstract Definitional Interpreters (Functional Pearl)**Research PapersGuannan Wei Purdue University, James Decker , Tiark Rompf Purdue University DOI
15:00 - 16:10 Continuations and EffectsResearch Papers at Stifel Theatre Chair(s): Martin Elsman University of Copenhagen, Denmark
15:0023mTalk **Capturing the Future by Replaying the Past (Functional Pearl)**Research PapersJames Koppel MIT, Gabriel Scherer INRIA Saclay, Armando Solar-Lezama MIT CSAIL DOI
15:2323mTalk **Handling Delimited Continuations with Dependent Types**Research PapersYouyou Cong Ochanomizu University, Japan, Kenichi Asai Ochanomizu University DOI
15:4623mTalk **Versatile Event Correlation with Algebraic Effects**Research PapersOliver Bračevac TU Darmstadt, Nada Amin University of Cambridge, Guido Salvaneschi TU Darmstadt, Sebastian Erdweg Delft University of Technology, Netherlands, Patrick Eugster Purdue University, Mira Mezini TU Darmstadt DOI
16:40 - 18:10 Probabilistic Programming and LearningResearch Papers at Stifel Theatre Chair(s): Michael Sperber Active Group GmbH
16:4022mTalk **The Simple Essence of Automatic DifferentiationDistinguished Paper**Research PapersConal Elliott Target, USA DOI
17:0222mTalk **Functional Programming for Modular Bayesian Inference**Research PapersAdam Ścibior University of Cambridge and MPI Tuebingen, Ohad Kammar University of Oxford, Zoubin Ghahramani University of Cambridge DOI
17:2522mTalk **Contextual Equivalence for a Probabilistic Language with Continuous Random Variables and Recursion**Research PapersMitchell Wand Northeastern University, USA, Ryan Culpepper Czech Technical University, Theophilos Giannakopoulos BAE Systems, Inc., Andrew Cobb Northeastern University DOI
17:4722mTalk **Teaching How to Program using Automated Assessment and Functional Glossy Games (Experience Report)**Research PapersJosé Bacelar Almeira University of Minho & INESC TEC, Alcino Cunha University of Minho and INESC TEC, Portugal, Nuno Macedo University of Minho & INESC TEC, Hugo Pacheco University of Minho, Portugal, José Proença HASLab/INESC TEC & University of Minho DOI
10:30 - 12:00 Compilation and ConcurrencyResearch Papers at Stifel Theatre Chair(s): Heather Miller Carnegie Mellon University
10:3022mTalk **Competitive Parallelism: Getting Your Priorities Right**Research PapersStefan K. Muller , Umut A. Acar Carnegie Mellon University, Robert Harper DOI
10:5222mTalk **Static Interpretation of Higher-Order Modules in Futhark: Functional GPU Programming in the Large**Research PapersMartin Elsman University of Copenhagen, Denmark, Troels Henriksen University of Copenhagen, Denmark, Danil Annenkov Department of Computer Science, University of Copenhagen, Cosmin Oancea University of Copenhagen, Denmark Link to publication DOI
11:1522mTalk **Finitary Polymorphism for Optimizing Type-Directed Compilation**Research PapersAtsushi Ohori Tohoku University, Japan, Katsuhiro Ueno Tohoku University, Hisayuki Mima Tohoku University DOI
11:3722mTalk **Fault Tolerant Functional Reactive Programming (Functional Pearl)**Research PapersIvan Perez National Institute of Aerospace, USA DOI
13:00 - 14:30 Proof Techniques and MechanizationResearch Papers at Stifel Theatre Chair(s): Niki Vazou University of Maryland, USA
13:0022mTalk **MoSeL: A General, Extensible Modal Framework for Interactive Proofs in Separation Logic**Research PapersRobbert Krebbers Delft University of Technology, Jacques-Henri Jourdan CNRS, LRI, Université Paris-Sud, Ralf Jung MPI-SWS, Joseph Tassarotti Carnegie Mellon University, Jan-Oliver Kaiser MPI-SWS, Amin Timany imec-Distrinet KU-Leuven, Arthur Charguéraud Inria, Derek Dreyer MPI-SWS DOI
13:2222mTalk **Mtac2: Typed Tactics for Backward Reasoning in Coq**Research PapersJan-Oliver Kaiser MPI-SWS, Beta Ziliani FAMAF, UNC and CONICET, Robbert Krebbers Delft University of Technology, Yann Régis-Gianas IRIF, University Paris Diderot and CNRS, France / INRIA PI.R2, Derek Dreyer MPI-SWS DOI
13:4522mTalk **Compositional Soundness Proofs of Abstract Interpreters**Research PapersSven Keidel Delft University of Technology, Netherlands, Casper Bach Delft University of Technology, Sebastian Erdweg Delft University of Technology, Netherlands DOI
14:0722mTalk **Equivalences for Free: Univalent Parametricity for Effective TransportDistinguished Paper**Research PapersNicolas Tabareau Inria, Éric Tanter University of Chile & Inria Paris, Matthieu Sozeau Inria DOI
15:00 - 16:30 Bidirectional ProgrammingResearch Papers at Stifel Theatre Chair(s): Wouter Swierstra Utrecht University, Netherlands
15:0022mTalk **What You Needa Know about Yoneda: Profunctor Optics and the Yoneda Lemma (Functional Pearl)**Research PapersGuillaume Boisseau University of Oxford, Jeremy Gibbons Department of Computer Science, University of Oxford DOI
15:2222mTalk **Incremental Relational Lenses**Research PapersRudi Horn University of Edinburgh, Roly Perera University of Glasgow, James Cheney University of Edinburgh, UK DOI
15:4522mTalk **Synthesizing Quotient Lenses**Research PapersSolomon Maina University of Pennsylvania, Anders Miltner Princeton University, Kathleen Fisher Tufts University, USA, Benjamin C. Pierce University of Pennsylvania, Dave Walker Princeton University, Steve Zdancewic University of Pennsylvania DOI
16:0722mTalk **Generic Deriving of Generic Traversals**Research PapersCsongor Kiss Imperial College London, Matthew Pickering University of Bristol, Nicolas Wu University of Bristol, UK DOI
10:30 - 12:00 SemanticsResearch Papers at Stifel Theatre Chair(s): Sam Lindley University of Edinburgh, UK
10:3022mTalk **Partially-Static Data as Free Extension of Algebras**Research PapersJeremy Yallop University of Cambridge, UK, Tamara von Glehn University of Cambridge, Ohad Kammar University of Oxford Link to publication DOI Pre-print
10:5222mTalk **Relational Algebra by Way of AdjunctionsDistinguished Paper**Research PapersJeremy Gibbons Department of Computer Science, University of Oxford, Fritz Henglein Department of Computer Science, University of Copenhagen (DIKU), Ralf Hinze Radboud University Nijmegen, Nicolas Wu University of Bristol, UK DOI
11:1522mTalk **Strict and Lazy Semantics for Effects: Layering Monads and Comonads**Research PapersAndrew K. Hirsch Cornell University, Ross Tate Cornell University DOI
11:3722mTalk **What's the Difference? A Functional Pearl on Subtracting Bijections**Research PapersBrent Yorgey Hendrix College, Kenneth Foner DOI
13:00 - 14:30 Gradual Typing and ProvingResearch Papers at Stifel Theatre Chair(s): Éric Tanter University of Chile & Inria Paris
13:0022mTalk **A Spectrum of Type Soundness and Performance**Research PapersBen Greenman Northeastern University, USA, Matthias Felleisen Northeastern University, USA DOI
13:2222mTalk **Casts and Costs: Harmonizing Safety and Performance in Gradual Typing**Research PapersJohn Peter Campora ULL Lafayette, Sheng Chen University of Louisiana at Lafayette, Eric Walkingshaw Oregon State University DOI
13:4522mTalk **Graduality from Embedding-Projection Pairs**Research PapersMax S. New Northeastern University, Amal Ahmed Northeastern University, USA DOI
14:0722mTalk **Ready, Set, Verify! Applying hs-to-coq to Real-World Haskell Code (Experience Report)**Research PapersJoachim Breitner DFINITY Foundation, Antal Spector-Zabusky , Yao Li University of Pennsylvania, Christine Rizkallah University of New South Wales, John Wiegley BAE Systems, Stephanie Weirich University of Pennsylvania, USA DOI
15:00 - 16:10 Complexity and BoundsResearch Papers at Stifel Theatre Chair(s): Ilya Sergey University College London
15:0023mTalk **Parallel Complexity Analysis with Temporal Session Types**Research PapersAnkush Das Carnegie Mellon University, Jan Hoffmann Carnegie Mellon University, Frank Pfenning Carnegie Mellon University, USA DOI
15:2323mTalk **Parametric Polymorphism and Operational Improvement**Research PapersJennifer Hackett University of Nottingham, UK, Graham Hutton University of Nottingham, UK DOI
15:4623mTalk **Tight Typings and Split Bounds**Research PapersBeniamino Accattoli Inria & Ecole Polytechnique, Stéphane Graham-Lengrand CNRS, France, Delia Kesner IRIF, France / University of Paris Diderot, France DOI

Accepted Papers

Title
A Spectrum of Type Soundness and PerformanceResearch PapersBen Greenman, Matthias Felleisen DOI
A Type and Scope Safe Universe of Syntaxes with Binding: Their Semantics and ProofsResearch PapersGuillaume Allais, Robert Atkey, James Chapman, Conor McBride, James McKinna DOI
Build Systems à la CarteDistinguished PaperResearch PapersAndrey Mokhov, Neil Mitchell, Simon Peyton Jones DOI
Capturing the Future by Replaying the Past (Functional Pearl)Research PapersJames Koppel, Gabriel Scherer, Armando Solar-Lezama DOI
Casts and Costs: Harmonizing Safety and Performance in Gradual TypingResearch PapersJohn Peter Campora, Sheng Chen, Eric Walkingshaw DOI
Competitive Parallelism: Getting Your Priorities RightResearch PapersStefan K. Muller, Umut A. Acar, Robert Harper DOI
Compositional Soundness Proofs of Abstract InterpretersResearch PapersSven Keidel, Casper Bach, Sebastian Erdweg DOI
Contextual Equivalence for a Probabilistic Language with Continuous Random Variables and RecursionResearch PapersMitchell Wand, Ryan Culpepper, Theophilos Giannakopoulos, Andrew Cobb DOI
Elaborating Dependent (Co)pattern MatchingResearch PapersJesper Cockx, Andreas Abel DOI
Equivalences for Free: Univalent Parametricity for Effective TransportDistinguished PaperResearch PapersNicolas Tabareau, Éric Tanter, Matthieu Sozeau DOI
Fault Tolerant Functional Reactive Programming (Functional Pearl)Research PapersIvan Perez DOI
Finitary Polymorphism for Optimizing Type-Directed CompilationResearch PapersAtsushi Ohori, Katsuhiro Ueno, Hisayuki Mima DOI
Functional Programming for Compiling and Decompiling Computer-Aided DesignResearch PapersChandrakana Nandi, James R. Wilcox, Taylor Blau, Dan Grossman, Zachary Tatlock DOI
Functional Programming for Modular Bayesian InferenceResearch PapersAdam Ścibior, Ohad Kammar, Zoubin Ghahramani DOI
Generic Deriving of Generic TraversalsResearch PapersCsongor Kiss, Matthew Pickering, Nicolas Wu DOI
Generic Zero-Cost Reuse for Dependent TypesResearch PapersLarry Diehl, Denis Firsov, Aaron Stump DOI
Graduality from Embedding-Projection PairsResearch PapersMax S. New, Amal Ahmed DOI
Handling Delimited Continuations with Dependent TypesResearch PapersYouyou Cong, Kenichi Asai DOI
Incremental Relational LensesResearch PapersRudi Horn, Roly Perera, James Cheney DOI
Keep Your Laziness in CheckResearch PapersKenneth Foner, Hengchu Zhang, Leonidas Lampropoulos DOI
Merlin: A Language Server for OCaml (Experience Report)Research PapersFrédéric Bour, Thomas Réfis, Gabriel Scherer DOI
MoSeL: A General, Extensible Modal Framework for Interactive Proofs in Separation LogicResearch PapersRobbert Krebbers, Jacques-Henri Jourdan, Ralf Jung, Joseph Tassarotti, Jan-Oliver Kaiser, Amin Timany, Arthur Charguéraud, Derek Dreyer DOI
Mtac2: Typed Tactics for Backward Reasoning in CoqResearch PapersJan-Oliver Kaiser, Beta Ziliani, Robbert Krebbers, Yann Régis-Gianas, Derek Dreyer DOI
Parallel Complexity Analysis with Temporal Session TypesResearch PapersAnkush Das, Jan Hoffmann, Frank Pfenning DOI
Parametric Polymorphism and Operational ImprovementResearch PapersJennifer Hackett, Graham Hutton DOI
Partially-Static Data as Free Extension of AlgebrasResearch PapersJeremy Yallop, Tamara von Glehn, Ohad Kammar Link to publication DOI Pre-print
Prototyping a Functional Language using Higher-Order Logic Programming: A Functional Pearl on Learning the Ways of λProlog/MakamResearch PapersAntonis Stampoulis, Adam Chlipala DOI
Ready, Set, Verify! Applying hs-to-coq to Real-World Haskell Code (Experience Report)Research PapersJoachim Breitner, Antal Spector-Zabusky, Yao Li, Christine Rizkallah, John Wiegley, Stephanie Weirich DOI
Reasonably Programmable Literal NotationResearch PapersCyrus Omar, Jonathan Aldrich Link to publication DOI
Refunctionalization of Abstract Abstract Machines: Bridging the Gap between Abstract Abstract Machines and Abstract Definitional Interpreters (Functional Pearl)Research PapersGuannan Wei, James Decker, Tiark Rompf DOI
Relational Algebra by Way of AdjunctionsDistinguished PaperResearch PapersJeremy Gibbons, Fritz Henglein, Ralf Hinze, Nicolas Wu DOI
Static Interpretation of Higher-Order Modules in Futhark: Functional GPU Programming in the LargeResearch PapersMartin Elsman, Troels Henriksen, Danil Annenkov, Cosmin Oancea Link to publication DOI
Strict and Lazy Semantics for Effects: Layering Monads and ComonadsResearch PapersAndrew K. Hirsch, Ross Tate DOI
Synthesizing Quotient LensesResearch PapersSolomon Maina, Anders Miltner, Kathleen Fisher, Benjamin C. Pierce, Dave Walker, Steve Zdancewic DOI
Teaching How to Program using Automated Assessment and Functional Glossy Games (Experience Report)Research PapersJosé Bacelar Almeira, Alcino Cunha, Nuno Macedo, Hugo Pacheco, José Proença DOI
The Simple Essence of Automatic DifferentiationDistinguished PaperResearch PapersConal Elliott DOI
Tight Typings and Split BoundsResearch PapersBeniamino Accattoli, Stéphane Graham-Lengrand, Delia Kesner DOI
Versatile Event Correlation with Algebraic EffectsResearch PapersOliver Bračevac, Nada Amin, Guido Salvaneschi, Sebastian Erdweg, Patrick Eugster, Mira Mezini DOI
What's the Difference? A Functional Pearl on Subtracting BijectionsResearch PapersBrent Yorgey, Kenneth Foner DOI
What You Needa Know about Yoneda: Profunctor Optics and the Yoneda Lemma (Functional Pearl)Research PapersGuillaume Boisseau, Jeremy Gibbons DOI

Call for Papers

Scope

PACMPL issue ICFP 2018 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):

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 2018 also welcomes submissions in two separate categories — Functional Pearls and Experience Reports — that must be marked as such at the time of submission 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 Friday, March 16, 2018, Anywhere on Earth (https://en.wikipedia.org/wiki/Anywhere_on_Earth). This deadline will be strictly enforced.

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) from https://www.acm.org/publications/authors/submissions. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from http://sigplan.org/Resources/Author/#acmart-format.

There is a limit of 27 pages for a full paper or 14 pages for an Experience Report; in either case, the bibliography will not be counted against these limits. These page limits have been chosen to allow essentially the same amount of content with the new single-column format as was possible with the two-column format used in past ICFP conferences. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting, will be summarily rejected.

See also PACMPL’s Information and Guidelines for Authors at https://pacmpl.acm.org/authors.cfm.

Submission: Submissions will be accepted at https://icfp18.hotcrp.com/

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 Wednesday, May 2, 2018, to read reviews and respond to them.

Supplementary Materials: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. The material should be uploaded at submission time, as a single pdf or a tarball, not via a URL. This supplementary material may or may not be anonymized; if not anonymized, it will only be revealed to reviewers after they have submitted their review of the paper and learned the identity of the author(s).

Authorship Policies: All submissions are expected to comply with the ACM Policies for Authorship that are detailed at https://www.acm.org/publications/authors/information-for-authors.

Republication Policies: Each submission must adhere to SIGPLAN’s republication policy, as explained on the web at http://www.sigplan.org/Resources/Policies/Republication.

Resubmitted Papers: Authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the principal editor will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews.

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 2018. We anticipate that there will be a need to clarify and expand on this process, and we will maintain a list of frequently asked questions and answers on the conference website to address common concerns.

PACMPL issue ICFP 2018 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. At the review meeting, a set of papers will be conditionally accepted and all other papers will be rejected. Authors will be notified of these decisions on May 18, 2018.

Authors of conditionally accepted papers will be provided with committee reviews (just as in previous conferences) along with a set of mandatory revisions. After five weeks (June 22, 2018), the authors will provide a second submission. The second and final reviewing phase assesses whether the mandatory revisions have been adequately addressed 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 five 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 2018 will employ a lightweight double-blind reviewing process. To facilitate this, 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 paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas.

Artifact Evaluation

Authors of papers that are conditionally accepted 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.

Further information about the motivations and expectations for Artifact Evaluation can be found at https://icfp18.sigplan.org/track/icfp-2018-Artifacts.

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:

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:

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.

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 which show how functional programming was used than from papers which 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 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 off submitted 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.

Previous versions of this FAQ were developed and refined by SIGPLAN officers and conference organizers with input from their committees and the community. Please contact the current program chair with any questions or comments about this version of the document.

Last updated: January 31, 2017

General

For authors

For reviewers

General

Q: Why are you using double-blind reviewing?

A: Our goal is to give each a reviewer an unbiased “first look” at each paper. Studies have shown that a reviewer’s attitude toward a submission may be affected, even unconsciously, by the identity of the author (see link below to more details). We want reviewers to be able to approach each submission without such involuntary reactions as “Barnaby; he writes a good paper” or “Who are these people? I have never heard of them.” For this reason, we ask that authors to omit their names from their submissions, and that they avoid revealing their identity through citation. Note that many systems and security conferences use double-blind reviewing and have done so for years (e.g., SIGCOMM, OSDI, IEEE Security and Privacy, SIGMOD). POPL and PLDI have done it for the last several years.

A key principle to keep in mind is that we intend this process to be cooperative, not adversarial. If a reviewer does discover an author’s identity through a subtle clue or oversight, then the author will not be penalized.

For those wanting more information, see the list of studies about gender bias in other fields and links to CS-related articles that cover this and other forms of bias below.

Q: Do you really think blinding actually works? I suspect reviewers can often guess who the authors are anyway.

A: Studies of blinding with the flavor we are using show that author identities remain unknown 53% to 79% of the time (see Snodgrass, linked below, for details). Moreover, about 5-10% of the time (again, see Snodgrass), a reviewer is certain of the authors, but then turns out to be at least partially mistaken. So, while sometimes authorship can be guessed correctly, the question is, is imperfect blinding better than no blinding at all? If author names are not explicitly in front of the reviewer on the front page, does that help at all even for the remaining submissions where it would be possible to guess? Our conjecture is that on balance the answer is “yes.”

Q: Couldn’t blind submission create an injustice where a paper is inappropriately rejected based upon supposedly-prior work which was actually by the same authors and not previously published?

A: This is indeed a serious issue. In the approach we are taking for ICFP ’18, author names are revealed to reviewers after they have submitted their review. Therefore, a reviewer can correct their review if they indeed have penalized the authors inappropriately. Unblinding prior to the PC meeting also avoids abuses in which committee members end up advancing the cause of a paper with which they have a conflict.

Q: What happens if the Program Chair has a conflict with the authors of a submitted paper?

A: The reviewing process for papers with which the Program Chair has a conflict will be managed by another PC member.

Q: Can you provide pointers to more information about bias in merit reviewing?

A: More detailed information on this topic has been gathered in the section at the end of this document.

For Authors

Q: What exactly do I have to do to anonymize my paper?

A: Your job is not to make your identity undiscoverable but simply to make it possible for our 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 (or list them as “omitted for submission”), 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. If you have any questions, feel free to ask the PC chair.

Q: I would like to provide supplementary material for consideration, such as the code of my implementation or the proofs of theorems. How do I do this?

A: On the submission site there will be an option to submit supplementary material along with your main paper. This supplementary material may or may not be anonymized; if not anonymized, it will only be revealed to reviewers after they have submitted their review of your paper and learned your identity. Reviewers are under no obligation to look at this material. The submission itself is the object of review and so it should strive to convince the reader of at least the plausibility of reported results; supplemental material only serves to confirm, in more detail, the idea argued in the paper. Of course, reviewers are free to change their review upon viewing supplemental material (or for any other reason). For those authors who wish to supplement, we encourage them to mention the supplement in the body of the paper so reviewers know to look for it, if necessary. For example, “The proof of Lemma 1 is included in the anonymous supplemental material submitted with this paper.”

Q: Is there a way for me to submit anonymous supplemental material which could be considered by a reviewer before she submits her review (rather than potentially non-anonymous material that can only be viewed afterward)?

A: Yes, submit it via HotCRP. Authors have been known to release a TR, code, etc. via an anonymous hosting service, and to include a URL to that material in the paper. However, we discourage authors from using such tactics except for materials that cannot, for some reason, be uploaded to the official site (e.g., a live demo). We emphasize that authors should strive to make their paper as convincing as possible within the submission page limit, in case reviewers choose not to access supplemental material. Also, see the next question.

Q: Can I supplement my submission using a URL that links to auxiliary materials instead of submitting such materials to the HotCRP system directly?

A In general, we discourage authors from providing supplementary materials via links to external web sites. It is possible to change the linked items after the submission deadline has passed, and, to be fair to all authors, we would like to be sure reviewers evaluate materials that have been completed prior to the submission deadline. Having said that, it is appropriate to link to items, such as an online demo, that cannot easily be submitted. Of course, attempting to discover the reviewers for your paper by tracking visitors to such a demo site would be a breach of academic integrity. Supplementary items such as PDFs should always be uploaded to HotCRP.

Q: I am building on my own past work on the WizWoz system. Do I need to rename this system in my paper for purposes of anonymity, so as to remove the implied connection between my authorship of past work on this system and my present submission?

A: No. The relationship between systems and authors changes over time, so there will be at least some doubt about authorship. Increasing this doubt by changing the system name would help with anonymity, but it would compromise the research process. In particular, changing the name requires explaining a lot about the system again because you can’t just refer to the existing papers, which use the proper name. Not citing these papers runs the risk of the reviewers who know about the existing system thinking you are replicating earlier work. It is also confusing for the reviewers to read about the paper under Name X and then have the name be changed to Name Y. Will all the reviewers go and re-read the final version with the correct name? If not, they have the wrong name in their heads, which could be harmful in the long run.

Q: I am submitting a paper that extends my own work that previously appeared at a workshop. Should I anonymize any reference to that prior work?

A: No. But we recommend you do not use the same title for your ICFP submission, so that it is clearly distinguished from the prior paper. In general there is rarely a good reason to anonymize a citation. One possibility is for work that is tightly related to the present submission and is also under review. But such works may often be non-anonymous. When in doubt, contact the PC Chair.

Q: Am I allowed to post my (non-blinded) paper on my web page? Can I advertise the unblinded version of my paper on mailing lists or send it to colleagues? May I give a talk about my work while it is under review?

A: As far as the authors’ publicity actions are concerned, a paper under double-blind review is largely the same as a paper under regular (single-blind) review. Double-blind reviewing should not hinder the usual communication of results.

That said, we do ask that you not attempt to deliberately subvert the double-blind reviewing process by announcing the names of the authors of your paper to the potential reviewers of your paper. It is difficult to define exactly what counts as “subversion” here, but generally speaking please refrain from sending individual e-mail to members of the PC or external reviewers about your work (unless they are conflicted out anyway).

It is perfectly fine, for example, to visit other institutions and give talks about your work, to present your submitted work during job interviews, to present your work at professional meetings (e.g., Dagstuhl), or to post your work on your web page. In general, PC members and external reviewers will not be asked to recuse themselves if they discover the (likely) identity of an author through such means.

Please refrain from posting the title of your paper on broadly visible social media or a major mailing list (e.g., TYPES). That's not so different from posting a submission on your web page, put the “push” nature of those mechanisms makes the information more difficult for potential reviewers to ignore. Posts that omit a paper’s title are less concerning. Of course, tweeting “submitted my ICFP paper” is encouraged!

If you are not sure about what constitutes “subversion,” please consult directly with the Program Chair.

Q: Will the fact that ICFP is double-blind have an impact on handling conflicts-of interest? When I am asked by the submission system to identify conflicts of interest, what criteria should I use?

A: Using DBR does not change the principle that reviewers should not review papers with which they have a conflict of interest, even if they do not immediately know who the authors are. Quoting (with slight alteration) from the ACM SIGPLAN review policies document:

A conflict of interest is defined as a situation in which the reviewer can be viewed as being able to benefit personally in the process of reviewing a paper. For example, if a reviewer is considering a paper written by a member of his own group, a current student, his advisor, or a group that he is seen as being in close competition with, then the outcome of the review process can have direct benefit to the reviewer’s own status. If a conflict of interest exists, the potential reviewer should decline to review the paper.

As an author, you should list PC members (and any others, because others may be asked for external reviews) that you believe have a conflict with you. While particular criteria for making this determination may vary, please apply the following guidelines, identifying a potential reviewer Bob as conflicted if

Also please identify institutions with which you are affiliated; all employees or affiliates of these institutions will also be considered conflicted.

If a possible reviewer does not meet the above criteria, please do not identify him/her as conflicted. Doing so could be viewed as an attempt to prevent a qualified, but possibly skeptical reviewer from reviewing your paper. If you nevertheless believe that a reviewer who does not meet the above criteria is conflicted, you may identify the person and send a note to the PC Chair.

For Reviewers

Q: What should I do if I if I learn the authors’ identity? What should I do if a prospective ICFP author contacts me and asks to visit my institution?

A: If at any point you feel that the authors’ actions are largely aimed at ensuring that potential reviewers know their identity, you should contact the Program Chair. Otherwise you should not treat double-blind reviewing differently from regular blind reviewing. In particular, you should refrain from seeking out information on the authors’ identity, but if you discover it accidentally this will not automatically disqualify you as a reviewer. Use your best judgment.

Q: The authors have provided a URL to supplemental material. I would like to see the material but I worry they will snoop my IP address and learn my identity. What should I do?

A: Contact the Program Chair, who will download the material on your behalf and make it available to you.

Q: If I am assigned a paper for which I feel I am not an expert, how do I seek an outside review?

A: PC members and external reviewers should do their own reviews, not delegate them to someone else. If doing so is problematic for some papers (e.g., you don’t feel completely qualified), then consider the following options. First, submit a review for your paper that is as careful as possible, outlining areas where you think your knowledge is lacking. Assuming we have sufficient expert reviews, that could be the end of it: non-expert reviews are valuable too, since conference attendees are by-and-large not experts for any given paper. Second, if you feel like the gaps in your knowledge are substantial, submit a first cut review, and then work with the PC chair to solicit an external review. This is easy: after submitting your review the paper is unblinded, so you at least know not to solicit the authors! You will also know other reviewers of the paper that have already been solicited. If none of these expert reviewers is acceptable to you, just check with the PC Chair that the person you do wish to solicit is not conflicted with the authors. In addition, the PC chair will attempt to balance the load on external reviewers. Keep in mind that while we would like the PC to make as informed a decision as possible about each submitted paper, each additional review we solicit places a burden on the community.

As a last resort, if you feel like your review would be extremely uninformed and you’d rather not even submit a first cut, contact the PC Chair, and another reviewer will be assigned.

Q: May I ask one of my students to do a review for me?

A: Having students (or interns at a research lab) participate in the review process is good for their education. However, you should not just “offload” your reviews to your students. Each review assigned to you is your responsibility. We recommend the following process: If you are sure that your student’s conflicts of interest are a subset of your own, you and your student may both begin to do your own separate reviews in parallel. (A student’s review should never simply be a substitute for your own work.) If your student’s conflicts of interest are not a subset of your own, you may do your own first-cut review first and then unblind the authors so you can check, or you may consult with the PC chair. Either way, once the student has completed their review, you should check the review to ensure the tone is professional and the content is appropriate. Then you may merge the student’s review with your own.

Q: How do I handle potential conflicts of interest given that I cannot see the author names?

A: The conference review system will ask that you identify conflicts of interest when you get an account on the submission system. Please see the related question applied to authors to decide how to identify conflicts. Feel free to also identify additional authors whose papers you feel you could not review fairly for reasons other than those given (e.g., strong personal friendship).

Q: Are PC members allowed to submit papers? If so, how are they handled?

A: PC submissions are allowed (except for the PC chair) with the usual condition of a higher standard (clearly as good as or better than other accepted papers, that is, strong support and no significant doubt). PC papers will be reviewed by the ERC, and they will not be discussed at the physical PC meeting.

Q: Are ERC members and external reviewers allowed to submit papers? If so, how are they handled?

A: ERC members and external reviewers are allowed to submit papers. Their papers will be reviewed like any other paper. There is no “higher standard” for ERC or external reviewer papers.

Q: How should I handle a paper I feel is very good, and yet would be a better fit for POPL (or PLDI or OOPSLA)?

A: The scope of ICFP is broad and encompasses all topics that pertain to functional programming. Hence, if you feel a paper would be an excellent POPL (or PLDI or OOPSLA) paper then it might also be an excellent ICFP paper. To be accepted at ICFP, a paper must discuss functional programming in some way, shape or form and it must have the potential to make a lasting impact on our field.

Q: How should I handle a paper that is out of scope for ICFP?

A: The scope of ICFP is broad and encompasses all topics that pertain to functional programming. However, if you discover you have been assigned a paper that does not contribute to the study of functional programming, please contact the program chair. We will discuss it and may decide to reject the paper on grounds of scope. Of course, if we decide after all that the paper is within the scope of ICFP, then you should review it like any other paper.

More Information about Bias in Merit Reviewing

Note that the information in this section has been put together by past and current organizers of the conference; not all of the program committee members or external reviewers are necessarily persuaded by it.

Kathryn McKinley’s editorial makes the case for double-blind reviewing from a computer science perspective. Her article cites Richard Snodgrass’s SIGMOD record editorial, which collects many studies of the effects of potential bias in peer review. The POPL ’12 Program Chair’s Report provides details about the introduction of double-blind reviewing in another SIGPLAN conference.

Here are a few studies on the potential effects of bias manifesting in a merit review process, focusing on bias against women. (These were collected by David Wagner.)

Snodgrass’ studies includes some of these, and more.