Call for Papers
ICFP 2007: International Conference on Functional Programming
Freiburg, Germany, 1–3 October 2007

ICFP 2007 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 and concurrency. Particular topics of interest include

A functional pearl needn't report original research results, but it must be instructive, elegant, and fun.

ICFP 2007 also seeks Experience Reports. An Experience Report is a short paper (2–4 pages) which need not present novel results, but which should provide evidence that functional programming really works or should describe obstacles that prevented it from working. Detailed guidelines are below.

What's new this year?

Experienced ICFP authors may want to pay special attention to the points below, which are new this year.

Instructions for authors

By 11:00 AM Friday, 6 April 2007, Samoan time, submit an abstract of at most 300 words and a full paper of at most 12 pages or an Experience Report of at most 4 pages. Submissions are now being accepted electronically through the CyberChair system at Submissions must be properly anonymized. The deadline is set at Samoan time, so if your submission is in by 11:00 AM Friday according to your local time, wherever you are, the submission will be on time. The world clock can give you the equivalent in your local time, e.g., 3:00 PM Friday in Portland, 6:00 PM Friday in Boston, and midnight Friday in Freiburg.

The deadline is firm.

Your 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. Make the technical content understandable to a broad audience.

Each submission must adhere to SIGPLAN's republication policy. This means in part that your paper may not have already appeared in a journal, conference, or workshop with published proceedings; that you may not submit substantially the same work simultaneously to ICFP and to another venue; and that your submission must discuss any closely related material, including your own, that was previously accepted at a journal, conference, or workshop with or without published proceedings. Full details of the policy are available at the SIGPLAN site. If you are in any doubt about whether this policy applies to your paper, either consult the program chair in advance or notify the chair when you submit. To do otherwise risks summary rejection of your submission.

If your submission is accepted, you must assign copyright to ACM. Proceedings will be published by the ACM Press.

Double-blind review:

To increase confidence in the fairness and objectivity of the reviewing process, reviewing will be double blind. Make it possible for reviewers to evaluate your paper without having to know who you are. It should suffice to omit your names from your submission and to avoid revealing your identity through citation; detailed guidelines are available here.


Your submission must be printable in black and white on US Letter sized paper and be either PDF or PostScript that is 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.

Your submission must be at most 12 pages (4 pages for an Experience Report), including bibliography and figures, in the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with pages 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). (A suitable LaTeX class file is available from SIGPLAN. Categories, keywords, and so on are optional.) If you wish to supply material beyond the 12-page limit, whether it be a small appendix, a full technical report, your source code, or even web pages, you may attach separate documents to your submission, on the understanding that reviewers are not expected to read them.

(As a particular example, if you feel that your submission should be supported by a lengthy technical report, do not cite such a technical report on the web, since doing so would reveal your identity. Please instead attach that report to your submission.) Detailed instructions for attaching supplementary documents will be available on the submission web site.

The length limit is firm; submissions that do not meet these guidelines will not be considered.


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

in your LaTeX preamble, and
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...''

Author response:

You will have a 48-hour period (11:00 23 May to 11:00 25 May 2007 Samoa time) to read and respond to reviews. Details of the author-response process will be available as it approaches.

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.

Functional pearls

To paraphrase both Jon Bentley and Richard Bird, the ideal pearl goes beyond solid engineering into the realm of insight and creativity. Just as a natural pearl grows from a grain of sand that has irritated an oyster, a topnotch functional pearl should grow from a real problem that has irritated a programmer. A pearl should be polished, elegant, instructive, and entertaining. Ideally it should teach important programming techniques and fundamental design principles. Past pearls have included instructive examples of program calculation or proof, nifty presentations of old or new data structures, and interesting applications and programming techniques.

Papers submitted to ICFP as pearls often miss the mark, by being too trivial, too complicated, or somehow not quite the elegant solution one hopes for. The key to an accepted pearl is polishing. 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 distasteful.

Richard Bird advises:

Experience reports

ICFP has long solicited submissions on the practice and experience of functional programming. But reports of experience are inherently different from research papers, and when judged by the criteria of scientific merit, novelty, or research contribution, they have not competed well against traditional ICFP submissions. Yet we believe that the functional-programming community would benefit from being able to draw on and cite the experience of others. For this reason, we have introduced the ICFP Experience Report.

Unlike a normal ICFP paper, the purpose of an Experience Report is not to add to the body of knowledge of the functional-programming community. Rather, 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 obstacles that prevented it from working.

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

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

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

Ralf Hinze (Universität Bonn)

Program Chair

Norman Ramsey
Harvard University
Cambridge, MA, 02138 USA
Phone: +1 617 496 8615
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 and reverse the charges.

Program Committee

Nick Benton (Microsoft Research)
Matthew Fluet (Toyota Technological Institute)
Jeremy Gibbons (University of Oxford)
Kevin Hammond (University of St Andrews)
Bastiaan Heeren (Utrecht University)
Graham Hutton (University of Nottingham)
Mark P. Jones (Portland State University)
Gabriele Keller (University of New South Wales)
Fabrice Le Fessant (INRIA/LIX, France)
Todd Millstein (UCLA)
Mike Sperber (DeinProgramm)
Christopher A. Stone (Harvey Mudd College)
Andrew Tolmach (Portland State University and INRIA Rocquencourt)
Janis Voigtländer (Technische Universität Dresden)
Stephanie Weirich (University of Pennsylvania)

Important Dates

Submission:11:00 6 April 2007, Samoa time (UTC-11)
Author response:11:00 23 May to 11:00 25 May 2007 (UTC-11)
Notification:8 June 2007
Final papers due:20 July 2007

ICFP 2007 Web Site

Special Issue of JFP

Authors of the best final papers, as determined by the program committee, will be invited to submit journal versions for a special issue of the Journal of Functional Programming.