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
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.
Experienced ICFP authors may want to pay special attention to the points below, which are new this year.
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 http://cyberchairpro.borbala.net/icfppapers/submit. 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.
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.
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...''
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.
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:
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.
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.
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.
Ralf Hinze (Universität Bonn)
| 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 |