[plt-scheme] ICFP09 Call for Papers

                           Call for Papers
    ICFP 2009: International Conference on Functional Programming
          Edinburgh, Scotland, 31 August - 2 September 2009
              http://www.cs.nott.ac.uk/~gmh/icfp09.html
               ** Submission deadline: 2 March 2009 **
             (submission deadline is earlier than usual)

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.

  * Special 'Call for Experience Reports' page, suitable as a target
    for posts on blogs and social networks to reach practitioners who
    wouldn't normally think about submitting to a conference.  If you
    have a blog, etc., please help by pointing your readers to:
    http://web.cecs.pdx.edu/~apt/icfp09_cfer.html


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

Submission:
~~~~~~~~~~~
Submissions will be accepted electronically at a URL to be named
later.  The deadline is set in Coordinated Universal Time. The world
clock (http://www.timeanddate.com/worldclock/fixedtime.html?month=3&day=2&year=2009&hour=20&min=0&sec=0&p1=0)
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.

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:
~~~~~~~~~~~~~~~~
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.

Functional Pearls
~~~~~~~~~~~~~~~~~
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.

Experience Reports
~~~~~~~~~~~~~~~~~~

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 at 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 (Universite de Montreal)
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)
~~~~~~~~~~~~~~~
Submission:           2 March 2009
Author response:  21-23 April 2009
Notification:           5 May 2009
Final papers due:      8 June 2009

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.