ICFP'09: Call for papers
Call for Papers
ICFP 2009: International Conference on Functional Programming
Edinburgh, Scotland, 31 August - 2 September 2009
The
submission page
is now closed
ICFP 2009 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, 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 or
concurrency. Particular topics of interest include
- Language Design:
type systems; concurrency and distribution; modules; components and composition;
metaprogramming; relations to object-oriented or logic programming; interoperability
- Implementation:
abstract machines; compilation; compile-time and run-time optimization;
memory management; 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
- Foundations:
formal semantics; lambda calculus; rewriting; type theory;
monads; continuations; control; state; effects
- Transformation and Analysis:
abstract interpretation; partial evaluation; program transformation;
program calculation; program proof
- Applications and Domain-Specific Languages:
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; multimedia programming;
scripting; system administration; security; education
- Functional Pearls:
elegant, instructive, and fun essays on functional programming
The conference also solicits Experience Reports,
which are short papers
that provide evidence
that functional programming really works or describe obstacles that have
kept it from working in a particular application.
What's different this year?
The conference dates and the submission deadline are about one month earlier than usual.
Instructions for authors
By
Monday, 2 March 2009, 20:00 UTC, submit an abstract of at most 300 words and a full paper of at most
12 pages (4 pages for an Experience Report), including bibliography
and figures.
The deadline will be strictly enforced and papers exceeding the page limits
will be summarily rejected.
Authors have the option to attach a separate file of supplementary material to a
submission, on the understanding that reviewers may choose not to look at it.
A submission will be evaluated according to its relevance, correctness,
significance, originality, and clarity.
It 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.
Functional Pearls and
Experience Reports are separate categories of papers that need
not report original research results and must be marked as such at the time of
submission.
Detailed guidelines on both categories are
below.
Each submission must adhere to
SIGPLAN's republication policy, as explained on the
web.
Violation risks summary rejection of the offending submission.
Proceedings will be published by ACM Press.
Authors of accepted submissions are expected to transfer the copyright to ACM.
Presentations will be videotaped and released online if the presenter consents
by signing an additional permission form at the time of the presentation.
Released videos will be included along with the conference proceedings in the
ACM Digital Library and may also be placed on a host such as YouTube or Google Video.
Formatting:
Submissions must be in PDF format printable in black and white on US Letter
sized paper and interpretable by Ghostscript.
If this
requirement is a hardship, make contact with the program chair at least one
week before the deadline.
ICFP proceedings are printed in black and white.
It is permissible to include color in a submission, but you risk
annoying reviewers who will have to decide if your final paper will be
understandable without it.
Papers must adhere to the standard ACM conference format: two columns,
nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and
54pc (9in) tall, with a column gutter of 2pc (0.33in).
Suitable document templates for LaTeX and Word are available from
SIGPLAN.
Submission:
Electronically at
https://www.softconf.com/a/icfp09.
The deadline is set in Coordinated Universal Time.
The world clock can give you the equivalent in your local time, e.g., Noon Monday in Seattle,
3:00 PM Monday in New York,
8:00 PM Monday in London,
5:00 AM Tuesday in Tokyo.
We recommend (but do not require) that
you put
your citations into author-date form.
This procedure makes your paper easier to review.
For example, if you cite a result on testing as ``(Claessen and Hughes
2000)'', many reviewers will recognize the result instantly.
On the other hand, if you cite it as ``[4]'', even the best-informed
reviewer has to page through your paper to find the
reference.
By using author-date form, you enable a knowledgeable reviewer to
focus on content, not arbitrary numbering of references.
LaTeX users can simply use the natbib package along with
the plainnat bibliography style.
In practice, this means putting
\usepackage{natbib}
\bibpunct();A{},
\let\cite=\citep
in your LaTeX preamble, and
\bibliographystyle{plainnat}
in your document.
For most citations you will use the \cite command;
if you want a citation like ``Claessen and Hughes (2000) showed
that...''
you should use something like
``\citet{claessen:quickcheck} showed...''
Alternatively, the McBride bibliography style, which adheres to the Chicago
manual of style ``Documentation Two'' specifications and which fixes some
perceived deficiencies of natbib, may be used. The style file along
with instructions for using it is available on the
McBride
web site.
Author response:
Authors will have a 48-hour period, starting at
20:00 UTC on 21 April 2009, to read and respond to reviews.
Special categories of papers
In addition to research papers, 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 four pages.
Authors submitting such papers may wish to consider the following advice.
A Functional Pearl is an elegant essay about something related to
functional programming. It might offer:
- 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
Functional Pearls are not restricted to the above varieties, however.
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. However, it
should be concise, instructive, and entertaining. Your pearl
is likely to be rejected if your 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 you wish to have 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. However, pearls
will be combined with ordinary papers for
the purpose of computing the conference's acceptance rate.
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 ICFP paper by its
title, by its length, and by the criteria used to evaluate it.
- Both in the proceedings and in any citations, the
title of each accepted Experience Report must begin with the words
``Experience Report'' followed by a colon.
The acceptance rate for Experience Reports will be computed and
reported separately from the rate for ordinary papers.
- An Experience Report is at most 4 pages long.
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 program 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:
make a claim about how well functional programming worked on your
project and why, and produce evidence to substantiate your claim.
If
functional programming worked for you in the same ways it has
worked for others, you need only to summarize the results---the main
part of your paper should discuss how well it worked and in what context.
Most readers will not want to know all the details of your project and
its implementation,
but please characterize your project and its context well enough so that
readers can judge to what degree your experience is relevant to their own
projects.
Be especially careful
to highlight any unusual aspects of your project.
Also keep in mind that specifics about your
project are more valuable than generalities about functional programming;
for example, it is more valuable to say that your team delivered its
software a month ahead of schedule than it is to say that functional
programming made your team more productive.
If your paper not only describes experience but also presents new technical
results,
or if your experience refutes cherished beliefs of the
functional-programming community,
you may be better off submitting it as a full paper, which
will be
judged by the usual criteria of novelty, originality, and relevance.
If you are unsure in which category to submit, the program chair will be
happy to help you decide.
Other information
Conference Chair
Graham Hutton (University of Nottingham)
Program Chair
Andrew Tolmach
Department of Computer Science
Portland State University
P.O. Box 751, Portland, OR 97207 USA
Email: apt@cs.pdx.edu
Phone: +1 503 725 5492
Fax: +1 503 725 3211
Mail sent to the address above is filtered for spam.
If you send mail and do not receive a prompt response,
particularly if the deadline is looming, feel free
to telephone.
Program Committee
Amal Ahmed (Toyota Technological Institute, Chicago)
Maria Alpuente (Technical University of Valencia (UPV))
Lennart Augustsson (Standard Chartered Bank)
Lars Birkedal (IT University of Copenhagen)
Manuel Chakravarty (University of New South Wales)
Koen Claessen (Chalmers University of Technology)
Marc Feeley (Université de Montréal)
Andrzej Filinski (University of Copenhagen)
Daan Leijen (Microsoft Research)
Xavier Leroy (INRIA Paris-Rocquencourt)
Conor McBride (University of Strathclyde)
Matthew Might (University of Utah)
Shin-Cheng Mu (Academia Sinica)
Atsushi Ohori (Tohoku University)
Kristoffer Rose (IBM Thomas J. Watson Research Center)
Important Dates (at 20:00 UTC)
ICFP 2009 Web Site
http://www.cs.nott.ac.uk/~gmh/icfp09.html
Special Journal Issue
There will be a special issue of the Journal of Functional Programming
with papers from ICFP 2009.
The program committee will invite the authors of select accepted papers to
submit a journal version to this issue.