ICFP 2016<br />
The 21st ACM SIGPLAN International Conference on Functional Programming<br />
http://conf.researchr.org/home/icfp-2016<br />
Call for Papers<br />
<br />
Important dates<br />
---------------<br />
<br />
Submissions due: Wednesday, March 16 2016, 15:00 (UTC)<br />
https://icfp2016.hotcrp.com<br />
(in preparation as of December 1)<br />
Author response: Monday, 2 May, 2016, 15:00 (UTC) -<br />
Thursday, 5 May, 2016, 15:00 (UTC)<br />
Notification: Friday, 20 May, 2016<br />
Final copy due: TBA<br />
Early registration: TBA<br />
Conference: Tuesday, 20 September -<br />
Thursday, 22 September, 2016<br />
<br />
Scope<br />
-----<br />
<br />
ICFP 2016 seeks original papers on the art and science of functional<br />
programming. Submissions are invited on all topics from principles to<br />
practice, from foundations to features, and from abstraction to<br />
application. The scope includes all languages that encourage<br />
functional programming, including both purely applicative and<br />
imperative languages, as well as languages with objects, concurrency,<br />
or parallelism. Topics of interest include (but are not limited to):<br />
<br />
- Language Design: concurrency, parallelism, and distribution;<br />
modules; components and composition; metaprogramming; type systems;<br />
interoperability; domain-specific languages; and relations to<br />
imperative, object-oriented, or logic programming.<br />
<br />
- Implementation: abstract machines; virtual machines; interpretation;<br />
compilation; compile-time and run-time optimization; garbage<br />
collection and memory management; multi-threading; exploiting<br />
parallel hardware; interfaces to foreign functions, services,<br />
components, or low-level machine resources.<br />
<br />
- Software-Development Techniques: algorithms and data structures;<br />
design patterns; specification; verification; validation; proof<br />
assistants; debugging; testing; tracing; profiling.<br />
<br />
- Foundations: formal semantics; lambda calculus; rewriting; type<br />
theory; monads; continuations; control; state; effects; program<br />
verification; dependent types.<br />
<br />
- Analysis and Transformation: control-flow; data-flow; abstract<br />
interpretation; partial evaluation; program calculation.<br />
<br />
- Applications: symbolic computing; formal-methods tools; artificial<br />
intelligence; systems programming; distributed-systems and web<br />
programming; hardware design; databases; XML processing; scientific<br />
and numerical computing; graphical user interfaces; multimedia and<br />
3D graphics programming; scripting; system administration; security.<br />
<br />
- Education: teaching introductory programming; parallel programming;<br />
mathematical proof; algebra.<br />
<br />
- Functional Pearls: elegant, instructive, and fun essays on<br />
functional programming.<br />
<br />
- Experience Reports: short papers that provide evidence that<br />
functional programming really works or describe obstacles that have<br />
kept it from working.<br />
<br />
If you are concerned about the appropriateness of some topic, do not<br />
hesitate to contact the program chair.<br />
<br />
Abbreviated instructions for authors<br />
------------------------------------<br />
<br />
- By Wednesday, March 16 2016, 15:00 (UTC), submit a full paper of at<br />
most 12 pages (6 pages for an Experience Report), in standard<br />
SIGPLAN conference format, including figures but ***excluding<br />
bibliography***.<br />
<br />
The deadlines will be strictly enforced and papers exceeding the page<br />
limits will be summarily rejected.<br />
<br />
***ICFP 2016 will employ a lightweight double-blind reviewing<br />
process.*** To facilitate this, submitted papers must adhere to two<br />
rules:<br />
<br />
1. ***author names and institutions must be omitted***, and<br />
<br />
2. ***references to authors' own related work should be in the third<br />
person*** (e.g., not "We build on our previous work ..." but<br />
rather "We build on the work of ...").<br />
<br />
The purpose of this process is to help the PC and external reviewers<br />
come to an initial judgement about the paper without bias, not to make<br />
it impossible for them to discover the authors if they were to<br />
try. Nothing should be done in the name of anonymity that weakens the<br />
submission or makes the job of reviewing the paper more difficult<br />
(e.g., important background references should not be omitted or<br />
anonymized). In addition, authors should feel free to disseminate<br />
their ideas or draft versions of their paper as they normally<br />
would. For instance, authors may post drafts of their papers on the<br />
web or give talks on their research ideas. We have put together a<br />
document answering frequently asked questions that should address many<br />
common concerns:<br />
http://conf.researchr.org/track/icfp-2016/icfp-2016-papers#Submission-and-Reviewing-FAQ<br />
<br />
- Authors have the option to attach supplementary material to a<br />
submission, on the understanding that reviewers may choose not to<br />
look at it. The material should be uploaded at submission time, as a<br />
single pdf or a tarball, not via a URL. This supplementary material<br />
may or may not be anonymized; if not anonymized, it will only be<br />
revealed to reviewers after they have submitted their review of your<br />
paper and learned your identity.<br />
<br />
- Each submission must adhere to SIGPLAN's republication policy, as<br />
explained on the web at:<br />
http://www.sigplan.org/Resources/Policies/Republication<br />
<br />
- Authors of resubmitted (but previously rejected) papers have the<br />
option to attach an annotated copy of the reviews of their previous<br />
submission(s), explaining how they have addressed these previous<br />
reviews in the present submission. If a reviewer identifies<br />
him/herself as a reviewer of this previous submission and wishes to<br />
see how his/her comments have been addressed, the program chair will<br />
communicate to this reviewer the annotated copy of his/her previous<br />
review. Otherwise, no reviewer will read the annotated copies of the<br />
previous reviews.<br />
<br />
Overall, a submission will be evaluated according to its relevance,<br />
correctness, significance, originality, and clarity. It should explain<br />
its contributions in both general and technical terms, clearly<br />
identifying what has been accomplished, explaining why it is<br />
significant, and comparing it with previous work. The technical<br />
content should be accessible to a broad audience. Functional Pearls<br />
and Experience Reports are separate categories of papers that need not<br />
report original research results and must be marked as such at the<br />
time of submission. Detailed guidelines on both categories are given<br />
below.<br />
<br />
Presentations will be videotaped and released online if the presenter<br />
consents. The proceedings will be freely available for download from<br />
the ACM Digital Library from at least one week before the start of the<br />
conference until two weeks after the conference.<br />
<br />
Formatting: Submissions must be in PDF format printable in black and<br />
white on US Letter sized paper and interpretable by<br />
Ghostscript. Papers must adhere to the standard SIGPLAN conference<br />
format: two columns, nine-point font on a ten-point baseline, with<br />
columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter<br />
of 2pc (0.33in). A suitable document template for LaTeX is available<br />
at http://www.sigplan.org/Resources/Author/<br />
<br />
Submission: Submissions will be accepted at<br />
https://icfp2016.hotcrp.com (in preparation as of December 1).<br />
<br />
Improved versions of a paper may be submitted at any point before the<br />
submission deadline using the same web interface.<br />
<br />
Author response: Authors will have a 72-hour period, starting at 15:00<br />
UTC on Monday, 2 May, 2016, to read reviews and respond to them.<br />
<br />
ACM Author-Izer is a unique service that enables ACM authors to<br />
generate and post links on either their home page or institutional<br />
repository for visitors to download the definitive version of their<br />
articles from the ACM Digital Library at no charge. Downloads through<br />
Author-Izer links are captured in official ACM statistics, improving<br />
the accuracy of usage and impact measurements. Consistently linking<br />
the definitive version of ACM article should reduce user confusion<br />
over article versioning. After your article has been published and<br />
assigned to your ACM Author Profile page, please visit<br />
http://www.acm.org/publications/acm-author-izer-service to learn how<br />
to create your links for free downloads from the ACM DL.<br />
<br />
Publication date: The official publication date of accepted papers is<br />
the date the proceedings are made available in the ACM Digital<br />
Library. This date may be up to two weeks prior to the first day of<br />
the conference. The official publication date affects the deadline for<br />
any patent filings related to published work.<br />
<br />
Special categories of papers<br />
----------------------------<br />
<br />
In addition to research papers, ICFP solicits two kinds of papers that<br />
do not require original research contributions: Functional Pearls,<br />
which are full papers, and Experience Reports, which are limited to<br />
six pages. Authors submitting such papers may wish to consider the<br />
following advice.<br />
<br />
Functional Pearls<br />
=================<br />
<br />
A Functional Pearl is an elegant essay about something related to<br />
functional programming. Examples include, but are not limited to:<br />
<br />
- a new and thought-provoking way of looking at an old idea<br />
- an instructive example of program calculation or proof<br />
- a nifty presentation of an old or new data structure<br />
- an interesting application of functional programming techniques<br />
- a novel use or exposition of functional programming in the classroom<br />
<br />
While pearls often demonstrate an idea through the development of a<br />
short program, there is no requirement or expectation that they do<br />
so. Thus, they encompass the notions of theoretical and educational<br />
pearls.<br />
<br />
Functional Pearls are valued as highly and judged as rigorously as<br />
ordinary papers, but using somewhat different criteria. In particular,<br />
a pearl is not required to report original research, but, it should be<br />
concise, instructive, and entertaining. Your pearl is likely to be<br />
rejected if your readers get bored, if the material gets too<br />
complicated, if too much specialized knowledge is needed, or if the<br />
writing is inelegant. The key to writing a good pearl is polishing.<br />
<br />
A submission you wish to have treated as a pearl must be marked as<br />
such on the submission web page, and should contain the words<br />
``Functional Pearl'' somewhere in its title or subtitle. These steps<br />
will alert reviewers to use the appropriate evaluation<br />
criteria. Pearls will be combined with ordinary papers, however, for<br />
the purpose of computing the conference's acceptance rate.<br />
<br />
Experience Reports<br />
==================<br />
<br />
The purpose of an Experience Report is to help create a body of<br />
published, refereed, citable evidence that functional programming<br />
really works -- or to describe what obstacles prevent it from working.<br />
<br />
Possible topics for an Experience Report include, but are not limited<br />
to:<br />
<br />
- insights gained from real-world projects using functional<br />
programming<br />
<br />
- comparison of functional programming with conventional programming<br />
in the context of an industrial project or a university curriculum<br />
<br />
- project-management, business, or legal issues encountered when using<br />
functional programming in a real-world project<br />
<br />
- curricular issues encountered when using functional programming in<br />
education<br />
<br />
- real-world constraints that created special challenges for an<br />
implementation of a functional language or for functional<br />
programming in general<br />
<br />
An Experience Report is distinguished from a normal ICFP paper by its<br />
title, by its length, and by the criteria used to evaluate it.<br />
<br />
- Both in the proceedings and in any citations, the title of each<br />
accepted Experience Report must begin with the words ``Experience<br />
Report'' followed by a colon. The acceptance rate for Experience<br />
Reports will be computed and reported separately from the rate for<br />
ordinary papers.<br />
<br />
- An Experience Report is at most six pages long. Each accepted<br />
Experience Report will be presented at the conference, but depending<br />
on the number of Experience Reports and regular papers accepted,<br />
authors of Experience reports may be asked to give shorter talks.<br />
<br />
- Because the purpose of Experience Reports is to enable our community<br />
to accumulate a body of evidence about the efficacy of functional<br />
programming, an acceptable Experience Report need not add to the<br />
body of knowledge of the functional-programming community by<br />
presenting novel results or conclusions. It is sufficient if the<br />
Report states a clear thesis and provides supporting evidence. The<br />
thesis must be relevant to ICFP, but it need not be novel.<br />
<br />
The program committee will accept or reject Experience Reports based<br />
on whether they judge the evidence to be convincing. Anecdotal<br />
evidence will be acceptable provided it is well argued and the author<br />
explains what efforts were made to gather as much evidence as<br />
possible. Typically, more convincing evidence is obtained from papers<br />
which show how functional programming was used than from papers which<br />
only say that functional programming was used. The most convincing<br />
evidence often includes comparisons of situations before and after the<br />
introduction or discontinuation of functional programming. Evidence<br />
drawn from a single person's experience may be sufficient, but more<br />
weight will be given to evidence drawn from the experience of groups<br />
of people.<br />
<br />
An Experience Report should be short and to the point: make a claim<br />
about how well functional programming worked on your project and why,<br />
and produce evidence to substantiate your claim. If functional<br />
programming worked for you in the same ways it has worked for others,<br />
you need only to summarize the results?the main part of your paper<br />
should discuss how well it worked and in what context. Most readers<br />
will not want to know all the details of your project and its<br />
implementation, but please characterize your project and its context<br />
well enough so that readers can judge to what degree your experience<br />
is relevant to their own projects. Be especially careful to highlight<br />
any unusual aspects of your project. Also keep in mind that specifics<br />
about your project are more valuable than generalities about<br />
functional programming; for example, it is more valuable to say that<br />
your team delivered its software a month ahead of schedule than it is<br />
to say that functional programming made your team more productive.<br />
<br />
If your paper not only describes experience but also presents new<br />
technical results, or if your experience refutes cherished beliefs of<br />
the functional-programming community, you may be better off submitting<br />
it as a full paper, which will be judged by the usual criteria of<br />
novelty, originality, and relevance. If you are unsure in which<br />
category to submit, the program chair will be happy to help you<br />
decide.<br />
<br />
Organizers<br />
----------<br />
<br />
General Co-Chairs:<br />
<br />
Jacques Garrigue (Nagoya University)<br />
Gabriele Keller (University of New South Wales)<br />
<br />
Program Chair:<br />
<br />
Eijiro Sumii (Tohoku University)<br />
<br />
Program Committee:<br />
<br />
Koen Claessen (Chalmers University of Technology)<br />
Joshua Dunfield (University of British Columbia, Canada)<br />
Matthew Fluet (Rochester Institute of Technology)<br />
Nate Foster (Cornell University)<br />
Dan Grossman (University of Washington, USA)<br />
Jurriaan Hage (Utrecht University)<br />
Roman Leshchinskiy (Standard Chartered Bank)<br />
Keisuke Nakano (The University of Electro-Communications)<br />
Aleksandar Nanevski (IMDEA Software Institute)<br />
Scott Owens (University of Kent)<br />
Sungwoo Park (Pohang University of Science and Technology)<br />
Amr Sabry (Indiana University)<br />
Tom Schrijvers (KU Leuven)<br />
Olin Shivers (Northeastern University)<br />
Walid Taha (Halmstad University)<br />
Dimitrios Vytiniotis (Microsoft Research, Cambridge)<br />
David Walker (Princeton University)<br />
Nobuko Yoshida (Imperial College London, UK)<br />
<br />
External Review Committee to be announced.<br />