Call for Papers
ICFP 2008: International Conference on Functional Programming
Victoria, BC, Canada, 22-24 September 2008

The submission page is open at https://www.softconf.com/s08/icfp08/submit.html

ICFP 2008 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

Experience Reports are also solicited, which are short papers (4 pages max) that provide evidence that functional programming really works or describe obstacles that have kept it from working in a particular application.

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.

What's different this year?

Instructions for authors

By Wednesday, 2 April 2008, 09:00 AM Apia time, 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 supplementary material to a submission, on the understanding that reviewers are not expected to read 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.

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. They may have the option to have their presentation videotaped and published along with the conference proceedings in the ACM Digital Library. Video recordings will only be released at the consent of the presenter, which is expressed by signing an additional copyright release/permission form.

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). A suitable document template for LaTeX is available from SIGPLAN.

Submission:

Electronically at https://www.softconf.com/s08/icfp08/submit.html. The deadline is set at Samoan time, so if your submission is in by 09:00 AM Wednesday 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.,1:00 PM Wednesday in Seattle, 4:00 PM Wednesday in New York, and 9:00 PM Wednesday in London.

Citation:

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:

You will have a 48-hour period, starting at 09:00 on 21 May 2008 Apia time, 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.

Functional Pearls

A Functional Pearl is an elegant essay about something related to functional programming. It might offer:

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.

A pearl 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.

Some advice from Richard Bird:

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 what obstacles prevent 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

James Hook (Portland State University)

Program Chair

Peter Thiemann
Albert-Ludwigs-Universität
Georges-Köhler-Allee 079
79110 Freiburg, Germany
Email: icfp08@informatik.uni-freiburg.de
Phone: +49 761 203 8051
Fax: +49 761 203 8052
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

Derek Dreyer (Max Planck Institute for Software Systems)
Robert Ennals (Intel Research)
Kathleen Fisher (AT&T Research)
Zhenjiang Hu (National Institute of Informatics)
Frank Huch (University of Kiel)
Andrew Kennedy (Microsoft Research)
Kevin Millikin (Google)
Henrik Nilsson (University of Nottingham)
Chris Okasaki (United States Military Academy)
Brigitte Pientka (McGill University)
Rinus Plasmeijer (University of Nijmegen)
Alan Schmitt (INRIA)
Chung-chieh Shan (Rutgers)
Mitchell Wand (Northeastern University)
Stephen Weeks (Jane Street Capital)

Important Dates (at 09:00 Apia time, UTC-11)

Submission:2 April 2008
Author response:21 May 2008
Notification:16 June 2008
Final papers due:9 July 2008

ICFP 2008 Web Site

http://www.icfpconference.org/icfp2008/

Special Journal Issue

There will be a special journal issue with papers from ICFP 2008. The program committee will invite the authors of select accepted papers to submit a journal version to this issue.