ICFP07 Call for Papers (Germany, Oct 07)

                                                          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
    * Applications and domain-specific languages: systems programming;
        scientific and numerical computing; symbolic computing; artificial
        intelligence; databases; graphical user interfaces; multimedia
        programming; scripting; system administration; distributed-systems and
        web programming; XML processing; security
    * Foundations: formal semantics; lambda calculus; type theory; monads;
        continuations; control; state; effects
    * Design: algorithms and data structures; modules; type systems;
        concurrency and distribution; components and composition; relations to
        object-oriented or logic programming
    * Implementation: abstract machines; compile-time and run-time
        optimization; just-in-time compilers; memory management; parallel
        hardware; interfaces to foreign functions, services, components or
        low-level machine resources
    * Transformation and analysis: abstract interpretation; partial
        evaluation; program transformation
    * Software-development techniques: design patterns; specification;
        verification; validation; debugging; test generation; tracing;
        profiling
    * Practice and experience: novel results drawn from experience in
        education or industry
    * Functional pearls: elegant, instructive examples of functional
        programming


A functional pearl need not 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 appear below.




What's new this year?
~~~~~~~~~~~~~~~~~~~~~
Experienced ICFP authors may want to pay special attention to the
points below, which are new this year.


    * Double-blind review
    * Author-date citations
    * Supplemental material in a separate document,
        not appended to the main text
    * Morning deadline (but equivalent to late afternoon or early evening in
        many time zones of interest)
    * Experience Reports








                                              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 will be accepted
electronically, at a URL to be named later. 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 at
http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=6&year=2007&
hour=11&min=0&sec=0&p1=282 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, which
appears in full at http://www.acm.org/sigplan/republicationpolicy.htm.
The policy 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 at http://icfp07.eecs.harvard.edu/blind.html.


Formatting
~~~~~~~~~~
Your submission must be printable 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.


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; see
http://www.acm.org/sigs/sigplan/authorInformation.htm. Categories,
keywords, and so on are optional.) If you wish to supply material
beyond the 12-page limit, up to and including a full technical report,
you may attach a separate document to your submission, on the
understanding that reviewers are not expected to read it. (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.


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.


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:
    * Throw away the rule book for writing research papers.
    * Get in quick; get out quick.
    * Be self-contained; don't go deep into related work, with lengthy
        references.
    * You are telling a story, so some element of surprise is welcome.
    * Above all, be engaging.
    * Give a talk on the pearl to non-specialists, your students, or your
        department. If you changed the order of presentation for the talk,
        consider using the new order in the next draft.
    * Put the pearl away for a while, then take it out and polish it
again.




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.


    * 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.


    * Experience Reports are limited in length: the suggested length is
        2 pages and the maximum length is 4 pages. 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 published, citable body of evidence about the efficacy
        of functional programming, an acceptable Experience Report need not
        present 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. The committee will be especially convinced by evidence that
        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


    * 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 should be short and to the point: 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 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, 02148 USA
Email: icfp07@eecs.harvard.edu
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 (AST)
Author response: 11:00 23 May to 11:00 25 May 2007 (AST)
Notification: 8 June 2007
Final papers due: 20 July 2007


ICFP 2007 Web Site
~~~~~~~~~~~~~~~~~~
http://www.informatik.uni-bonn.de/~ralf/icfp07.html


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.

Return to the comp.compilers page.
Search the comp.compilers archives again.