* [Caml-list] ICFP 2016 Call for Papers
@ 2015-12-06 3:39 Lindsey Kuper
2015-12-06 8:24 ` [Caml-list] Here comes the time Roberto Di Cosmo
2015-12-07 9:05 ` [Caml-list] ICFP 2016 Call for Papers Lindsey Kuper
0 siblings, 2 replies; 3+ messages in thread
From: Lindsey Kuper @ 2015-12-06 3:39 UTC (permalink / raw)
To: caml-list
[-- Attachment #1: Type: text/plain, Size: 16525 bytes --]
ICFP 2016
The 21st ACM SIGPLAN International Conference on Functional Programming
http://conf.researchr.org/home/icfp-2016
Call for Papers
Important dates
---------------
Submissions due: Wednesday, March 16 2016, 15:00 (UTC)
https://icfp2016.hotcrp.com
(in
preparation as of December 1)
Author response: Monday, 2 May, 2016, 15:00 (UTC) -
Thursday, 5 May, 2016, 15:00 (UTC)
Notification: Friday, 20 May, 2016
Final copy due: TBA
Early registration: TBA
Conference: Tuesday, 20 September -
Thursday, 22 September, 2016
Scope
-----
ICFP 2016 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, and 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, concurrency,
or parallelism. Topics of interest include (but are not limited to):
- Language Design: concurrency, parallelism, and distribution;
modules; components and composition; metaprogramming; type systems;
interoperability; domain-specific languages; and relations to
imperative, object-oriented, or logic programming.
- Implementation: abstract machines; virtual machines; interpretation;
compilation; compile-time and run-time optimization; garbage
collection and 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; program
verification; dependent types.
- Analysis and Transformation: control-flow; data-flow; abstract
interpretation; partial evaluation; program calculation.
- Applications: 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 and
3D graphics programming; scripting; system administration; security.
- Education: teaching introductory programming; parallel programming;
mathematical proof; algebra.
- Functional Pearls: elegant, instructive, and fun essays on
functional programming.
- Experience Reports: short papers that provide evidence that
functional programming really works or describe obstacles that have
kept it from working.
If you are concerned about the appropriateness of some topic, do not
hesitate to contact the program chair.
Abbreviated instructions for authors
------------------------------------
- By Wednesday, March 16 2016, 15:00 (UTC), submit a full paper of at
most 12 pages (6 pages for an Experience Report), in standard
SIGPLAN conference format, including figures but ***excluding
bibliography***.
The deadlines will be strictly enforced and papers exceeding the page
limits will be summarily rejected.
***ICFP 2016 will employ a lightweight double-blind reviewing
process.*** To facilitate this, submitted papers must adhere to two
rules:
1. ***author names and institutions must be omitted***, and
2. ***references to authors' own related work should be in the
third
person*** (e.g., not "We build on our previous
work ..." but
rather "We build on the work of ...").
The purpose of this process is to help the PC and external reviewers
come to an initial judgement about the paper without bias, not to make
it impossible for them to discover the authors if they were to
try. Nothing should be done in the name of anonymity that weakens the
submission or makes the job of reviewing the paper more difficult
(e.g., important background references should not be omitted or
anonymized). In addition, authors should feel free to disseminate
their ideas or draft versions of their paper as they normally
would. For instance, authors may post drafts of their papers on the
web or give talks on their research ideas. We have put together a
document answering frequently asked questions that should address many
common concerns:
http://conf.researchr.org/track/icfp-2016/icfp-2016-papers#Submission-and-Reviewing-FAQ
- Authors have the option to attach supplementary material to a
submission, on the understanding that reviewers may choose not to
look at it. The material should be uploaded at submission time, as a
single pdf or a tarball, not via a URL. This supplementary material
may or may not be anonymized; if not anonymized, it will only be
revealed to reviewers after they have submitted their review of your
paper and learned your identity.
- Each submission must adhere to SIGPLAN's republication policy, as
explained on the web at:
http://www.sigplan.org/Resources/Policies/Republication
- Authors of resubmitted (but previously rejected) papers have the
option to attach an annotated copy of the reviews of their previous
submission(s), explaining how they have addressed these previous
reviews in the present submission. If a reviewer identifies
him/herself as a reviewer of this previous submission and wishes to
see how his/her comments have been addressed, the program chair will
communicate to this reviewer the annotated copy of his/her previous
review. Otherwise, no reviewer will read the annotated copies of the
previous reviews.
Overall, 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 given
below.
Presentations will be videotaped and released online if the presenter
consents. The proceedings will be freely available for download from
the ACM Digital Library from at least one week before the start of the
conference until two weeks after the conference.
Formatting: Submissions must be in PDF format printable in black and
white on US Letter sized paper and interpretable by
Ghostscript. Papers must adhere to the standard SIGPLAN 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
at http://www.sigplan.org/Resources/Author/
Submission: Submissions will be accepted at
https://icfp2016.hotcrp.com (in preparation as of December 1).
Improved versions of a paper may be submitted at any point before the
submission deadline using the same web interface.
Author response: Authors will have a 72-hour period, starting at 15:00
UTC on Monday, 2 May, 2016, to read reviews and respond to them.
ACM Author-Izer is a unique service that enables ACM authors to
generate and post links on either their home page or institutional
repository for visitors to download the definitive version of their
articles from the ACM Digital Library at no charge. Downloads through
Author-Izer links are captured in official ACM statistics, improving
the accuracy of usage and impact measurements. Consistently linking
the definitive version of ACM article should reduce user confusion
over article versioning. After your article has been published and
assigned to your ACM Author Profile page, please visit
http://www.acm.org/publications/acm-author-izer-service to learn how
to create your links for free downloads from the ACM DL.
Publication date: The official publication date of accepted papers is
the date the proceedings are made available in the ACM Digital
Library. This date may be up to two weeks prior to the first day of
the conference. The official publication date affects the deadline for
any patent filings related to published work.
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
six 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. Examples include, but are not limited to:
- 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
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, but, 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. Pearls will be combined with ordinary papers, however, 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 six 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.
Organizers
----------
General Co-Chairs:
Jacques Garrigue (Nagoya University)
Gabriele Keller (University of New South Wales)
Program Chair:
Eijiro Sumii (Tohoku University)
Program Committee:
Koen Claessen (Chalmers University of Technology)
Joshua Dunfield (University of British Columbia, Canada)
Matthew Fluet (Rochester Institute of Technology)
Nate Foster (Cornell University)
Dan Grossman (University of Washington, USA)
Jurriaan Hage (Utrecht University)
Roman Leshchinskiy (Standard Chartered Bank)
Keisuke Nakano (The University of Electro-Communications)
Aleksandar Nanevski (IMDEA Software Institute)
Scott Owens (University of Kent)
Sungwoo Park (Pohang University of Science and Technology)
Amr Sabry (Indiana University)
Tom Schrijvers (KU Leuven)
Olin Shivers (Northeastern University)
Walid Taha (Halmstad University)
Dimitrios Vytiniotis (Microsoft Research, Cambridge)
David Walker (Princeton University)
Nobuko Yoshida (Imperial College London, UK)
External Review Committee to be announced.
[-- Attachment #2: Type: text/html, Size: 18539 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Caml-list] Here comes the time ...
2015-12-06 3:39 [Caml-list] ICFP 2016 Call for Papers Lindsey Kuper
@ 2015-12-06 8:24 ` Roberto Di Cosmo
2015-12-07 9:05 ` [Caml-list] ICFP 2016 Call for Papers Lindsey Kuper
1 sibling, 0 replies; 3+ messages in thread
From: Roberto Di Cosmo @ 2015-12-06 8:24 UTC (permalink / raw)
To: ocamlmooc; +Cc: caml-list
... of planning a paper for ICFP 2016!
Ok, ok, on revient au francais.
En bref, ceci est un message preliminaire pour savoir qui serait interesse a
contribuer activement et de facon significative a un papier pour ICFP 2016
sur le MOOC OCaml qui est en train de se terminer: je veux bien prendre
le lead sur le papier, mais il me faut au moins deux ou trois autres
personnes prete a y passer vraiement du temps pour etre surs que cela
va passer
--
Roberto
P.S.: bien sur, tout le monde sera explicitement mentionne dans la
section Acknowledgement, la je cherche les personnes qui acceptent
de bosser suffisamment sur le papier pour etre dans le champs "auteur" :-)
On Sun, Dec 06, 2015 at 03:39:52AM +0000, Lindsey Kuper wrote:
> ICFP 2016
> The 21st ACM SIGPLAN International Conference on Functional Programming
> http://conf.researchr.org/home/icfp-2016
> Call for Papers
>
> Important dates
> ---------------
>
> Submissions due: Wednesday, March 16 2016, 15:00 (UTC)
> https://icfp2016.hotcrp.com
> (in preparation as of December 1)
> Author response: Monday, 2 May, 2016, 15:00 (UTC) -
> Thursday, 5 May, 2016, 15:00 (UTC)
> Notification: Friday, 20 May, 2016
> Final copy due: TBA
> Early registration: TBA
> Conference: Tuesday, 20 September -
> Thursday, 22 September, 2016
>
> Scope
> -----
>
> ICFP 2016 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, and 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, concurrency,
> or parallelism. Topics of interest include (but are not limited to):
>
> - Language Design: concurrency, parallelism, and distribution;
> modules; components and composition; metaprogramming; type systems;
> interoperability; domain-specific languages; and relations to
> imperative, object-oriented, or logic programming.
>
> - Implementation: abstract machines; virtual machines; interpretation;
> compilation; compile-time and run-time optimization; garbage
> collection and 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; program
> verification; dependent types.
>
> - Analysis and Transformation: control-flow; data-flow; abstract
> interpretation; partial evaluation; program calculation.
>
> - Applications: 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 and
> 3D graphics programming; scripting; system administration; security.
>
> - Education: teaching introductory programming; parallel programming;
> mathematical proof; algebra.
>
> - Functional Pearls: elegant, instructive, and fun essays on
> functional programming.
>
> - Experience Reports: short papers that provide evidence that
> functional programming really works or describe obstacles that have
> kept it from working.
>
> If you are concerned about the appropriateness of some topic, do not
> hesitate to contact the program chair.
>
> Abbreviated instructions for authors
> ------------------------------------
>
> - By Wednesday, March 16 2016, 15:00 (UTC), submit a full paper of at
> most 12 pages (6 pages for an Experience Report), in standard
> SIGPLAN conference format, including figures but ***excluding
> bibliography***.
>
> The deadlines will be strictly enforced and papers exceeding the page
> limits will be summarily rejected.
>
> ***ICFP 2016 will employ a lightweight double-blind reviewing
> process.*** To facilitate this, submitted papers must adhere to two
> rules:
>
> 1. ***author names and institutions must be omitted***, and
>
> 2. ***references to authors' own related work should be in the third
> person*** (e.g., not "We build on our previous work ..." but
> rather "We build on the work of ...").
>
> The purpose of this process is to help the PC and external reviewers
> come to an initial judgement about the paper without bias, not to make
> it impossible for them to discover the authors if they were to
> try. Nothing should be done in the name of anonymity that weakens the
> submission or makes the job of reviewing the paper more difficult
> (e.g., important background references should not be omitted or
> anonymized). In addition, authors should feel free to disseminate
> their ideas or draft versions of their paper as they normally
> would. For instance, authors may post drafts of their papers on the
> web or give talks on their research ideas. We have put together a
> document answering frequently asked questions that should address many
> common concerns:
> http://conf.researchr.org/track/icfp-2016/icfp-2016-papers#
> Submission-and-Reviewing-FAQ
>
> - Authors have the option to attach supplementary material to a
> submission, on the understanding that reviewers may choose not to
> look at it. The material should be uploaded at submission time, as a
> single pdf or a tarball, not via a URL. This supplementary material
> may or may not be anonymized; if not anonymized, it will only be
> revealed to reviewers after they have submitted their review of your
> paper and learned your identity.
>
> - Each submission must adhere to SIGPLAN's republication policy, as
> explained on the web at:
> http://www.sigplan.org/Resources/Policies/Republication
>
> - Authors of resubmitted (but previously rejected) papers have the
> option to attach an annotated copy of the reviews of their previous
> submission(s), explaining how they have addressed these previous
> reviews in the present submission. If a reviewer identifies
> him/herself as a reviewer of this previous submission and wishes to
> see how his/her comments have been addressed, the program chair will
> communicate to this reviewer the annotated copy of his/her previous
> review. Otherwise, no reviewer will read the annotated copies of the
> previous reviews.
>
> Overall, 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 given
> below.
>
> Presentations will be videotaped and released online if the presenter
> consents. The proceedings will be freely available for download from
> the ACM Digital Library from at least one week before the start of the
> conference until two weeks after the conference.
>
> Formatting: Submissions must be in PDF format printable in black and
> white on US Letter sized paper and interpretable by
> Ghostscript. Papers must adhere to the standard SIGPLAN 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
> at http://www.sigplan.org/Resources/Author/
>
> Submission: Submissions will be accepted at
> https://icfp2016.hotcrp.com (in preparation as of December 1).
>
> Improved versions of a paper may be submitted at any point before the
> submission deadline using the same web interface.
>
> Author response: Authors will have a 72-hour period, starting at 15:00
> UTC on Monday, 2 May, 2016, to read reviews and respond to them.
>
> ACM Author-Izer is a unique service that enables ACM authors to
> generate and post links on either their home page or institutional
> repository for visitors to download the definitive version of their
> articles from the ACM Digital Library at no charge. Downloads through
> Author-Izer links are captured in official ACM statistics, improving
> the accuracy of usage and impact measurements. Consistently linking
> the definitive version of ACM article should reduce user confusion
> over article versioning. After your article has been published and
> assigned to your ACM Author Profile page, please visit
> http://www.acm.org/publications/acm-author-izer-service to learn how
> to create your links for free downloads from the ACM DL.
>
> Publication date: The official publication date of accepted papers is
> the date the proceedings are made available in the ACM Digital
> Library. This date may be up to two weeks prior to the first day of
> the conference. The official publication date affects the deadline for
> any patent filings related to published work.
>
> 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
> six 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. Examples include, but are not limited to:
>
> - 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
>
> 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, but, 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. Pearls will be combined with ordinary papers, however, 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 six 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.
>
> Organizers
> ----------
>
> General Co-Chairs:
>
> Jacques Garrigue (Nagoya University)
> Gabriele Keller (University of New South Wales)
>
> Program Chair:
>
> Eijiro Sumii (Tohoku University)
>
> Program Committee:
>
> Koen Claessen (Chalmers University of Technology)
> Joshua Dunfield (University of British Columbia, Canada)
> Matthew Fluet (Rochester Institute of Technology)
> Nate Foster (Cornell University)
> Dan Grossman (University of Washington, USA)
> Jurriaan Hage (Utrecht University)
> Roman Leshchinskiy (Standard Chartered Bank)
> Keisuke Nakano (The University of Electro-Communications)
> Aleksandar Nanevski (IMDEA Software Institute)
> Scott Owens (University of Kent)
> Sungwoo Park (Pohang University of Science and Technology)
> Amr Sabry (Indiana University)
> Tom Schrijvers (KU Leuven)
> Olin Shivers (Northeastern University)
> Walid Taha (Halmstad University)
> Dimitrios Vytiniotis (Microsoft Research, Cambridge)
> David Walker (Princeton University)
> Nobuko Yoshida (Imperial College London, UK)
>
> External Review Committee to be announced.
--
Roberto Di Cosmo
------------------------------------------------------------------
Professeur En detachement a l'INRIA
PPS E-mail: roberto@dicosmo.org
Universite Paris Diderot WWW : http://www.dicosmo.org
Case 7014 Tel : ++33-(0)1-57 27 92 20
5, Rue Thomas Mann
F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo
FRANCE. Twitter: http://twitter.com/rdicosmo
------------------------------------------------------------------
Attachments:
MIME accepted, Word deprecated
http://www.gnu.org/philosophy/no-word-attachments.html
------------------------------------------------------------------
Office location:
Bureau 3020 (3rd floor)
Batiment Sophie Germain
8 place Aurélie Nemours
Metro Bibliotheque Francois Mitterrand, ligne 14/RER C
-----------------------------------------------------------------
GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Caml-list] ICFP 2016 Call for Papers
2015-12-06 3:39 [Caml-list] ICFP 2016 Call for Papers Lindsey Kuper
2015-12-06 8:24 ` [Caml-list] Here comes the time Roberto Di Cosmo
@ 2015-12-07 9:05 ` Lindsey Kuper
1 sibling, 0 replies; 3+ messages in thread
From: Lindsey Kuper @ 2015-12-07 9:05 UTC (permalink / raw)
To: caml-list
[My apologies for the garbled text in a previous version of this
email. -- Lindsey]
ICFP 2016
The 21st ACM SIGPLAN International Conference on Functional Programming
http://conf.researchr.org/home/icfp-2016
Call for Papers
Important dates
---------------
Submissions due: Wednesday, March 16 2016, 15:00 (UTC)
https://icfp2016.hotcrp.com
(in preparation as of December 1)
Author response: Monday, 2 May, 2016, 15:00 (UTC) -
Thursday, 5 May, 2016, 15:00 (UTC)
Notification: Friday, 20 May, 2016
Final copy due: TBA
Early registration: TBA
Conference: Tuesday, 20 September -
Thursday, 22 September, 2016
Scope
-----
ICFP 2016 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, and 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, concurrency,
or parallelism. Topics of interest include (but are not limited to):
- Language Design: concurrency, parallelism, and distribution;
modules; components and composition; metaprogramming; type systems;
interoperability; domain-specific languages; and relations to
imperative, object-oriented, or logic programming.
- Implementation: abstract machines; virtual machines; interpretation;
compilation; compile-time and run-time optimization; garbage
collection and 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; program
verification; dependent types.
- Analysis and Transformation: control-flow; data-flow; abstract
interpretation; partial evaluation; program calculation.
- Applications: 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 and
3D graphics programming; scripting; system administration; security.
- Education: teaching introductory programming; parallel programming;
mathematical proof; algebra.
- Functional Pearls: elegant, instructive, and fun essays on
functional programming.
- Experience Reports: short papers that provide evidence that
functional programming really works or describe obstacles that have
kept it from working.
If you are concerned about the appropriateness of some topic, do not
hesitate to contact the program chair.
Abbreviated instructions for authors
------------------------------------
- By Wednesday, March 16 2016, 15:00 (UTC), submit a full paper of at
most 12 pages (6 pages for an Experience Report), in standard
SIGPLAN conference format, including figures but ***excluding
bibliography***.
The deadlines will be strictly enforced and papers exceeding the page
limits will be summarily rejected.
***ICFP 2016 will employ a lightweight double-blind reviewing
process.*** To facilitate this, submitted papers must adhere to two
rules:
1. ***author names and institutions must be omitted***, and
2. ***references to authors' own related work should be in the third
person*** (e.g., not "We build on our previous work ..." but
rather "We build on the work of ...").
The purpose of this process is to help the PC and external reviewers
come to an initial judgement about the paper without bias, not to make
it impossible for them to discover the authors if they were to
try. Nothing should be done in the name of anonymity that weakens the
submission or makes the job of reviewing the paper more difficult
(e.g., important background references should not be omitted or
anonymized). In addition, authors should feel free to disseminate
their ideas or draft versions of their paper as they normally
would. For instance, authors may post drafts of their papers on the
web or give talks on their research ideas. We have put together a
document answering frequently asked questions that should address many
common concerns:
http://conf.researchr.org/track/icfp-2016/icfp-2016-papers#Submission-and-Reviewing-FAQ
- Authors have the option to attach supplementary material to a
submission, on the understanding that reviewers may choose not to
look at it. The material should be uploaded at submission time, as a
single pdf or a tarball, not via a URL. This supplementary material
may or may not be anonymized; if not anonymized, it will only be
revealed to reviewers after they have submitted their review of your
paper and learned your identity.
- Each submission must adhere to SIGPLAN's republication policy, as
explained on the web at:
http://www.sigplan.org/Resources/Policies/Republication
- Authors of resubmitted (but previously rejected) papers have the
option to attach an annotated copy of the reviews of their previous
submission(s), explaining how they have addressed these previous
reviews in the present submission. If a reviewer identifies
him/herself as a reviewer of this previous submission and wishes to
see how his/her comments have been addressed, the program chair will
communicate to this reviewer the annotated copy of his/her previous
review. Otherwise, no reviewer will read the annotated copies of the
previous reviews.
Overall, 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 given
below.
Presentations will be videotaped and released online if the presenter
consents. The proceedings will be freely available for download from
the ACM Digital Library from at least one week before the start of the
conference until two weeks after the conference.
Formatting: Submissions must be in PDF format printable in black and
white on US Letter sized paper and interpretable by
Ghostscript. Papers must adhere to the standard SIGPLAN 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
at http://www.sigplan.org/Resources/Author/
Submission: Submissions will be accepted at
https://icfp2016.hotcrp.com (in preparation as of December 1).
Improved versions of a paper may be submitted at any point before the
submission deadline using the same web interface.
Author response: Authors will have a 72-hour period, starting at 15:00
UTC on Monday, 2 May, 2016, to read reviews and respond to them.
ACM Author-Izer is a unique service that enables ACM authors to
generate and post links on either their home page or institutional
repository for visitors to download the definitive version of their
articles from the ACM Digital Library at no charge. Downloads through
Author-Izer links are captured in official ACM statistics, improving
the accuracy of usage and impact measurements. Consistently linking
the definitive version of ACM article should reduce user confusion
over article versioning. After your article has been published and
assigned to your ACM Author Profile page, please visit
http://www.acm.org/publications/acm-author-izer-service to learn how
to create your links for free downloads from the ACM DL.
Publication date: The official publication date of accepted papers is
the date the proceedings are made available in the ACM Digital
Library. This date may be up to two weeks prior to the first day of
the conference. The official publication date affects the deadline for
any patent filings related to published work.
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
six 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. Examples include, but are not limited to:
- 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
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, but, 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. Pearls will be combined with ordinary papers, however, 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 six 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.
Organizers
----------
General Co-Chairs:
Jacques Garrigue (Nagoya University)
Gabriele Keller (University of New South Wales)
Program Chair:
Eijiro Sumii (Tohoku University)
Program Committee:
Koen Claessen (Chalmers University of Technology)
Joshua Dunfield (University of British Columbia, Canada)
Matthew Fluet (Rochester Institute of Technology)
Nate Foster (Cornell University)
Dan Grossman (University of Washington, USA)
Jurriaan Hage (Utrecht University)
Roman Leshchinskiy (Standard Chartered Bank)
Keisuke Nakano (The University of Electro-Communications)
Aleksandar Nanevski (IMDEA Software Institute)
Scott Owens (University of Kent)
Sungwoo Park (Pohang University of Science and Technology)
Amr Sabry (Indiana University)
Tom Schrijvers (KU Leuven)
Olin Shivers (Northeastern University)
Walid Taha (Halmstad University)
Dimitrios Vytiniotis (Microsoft Research, Cambridge)
David Walker (Princeton University)
Nobuko Yoshida (Imperial College London, UK)
External Review Committee to be announced.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-12-07 9:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-06 3:39 [Caml-list] ICFP 2016 Call for Papers Lindsey Kuper
2015-12-06 8:24 ` [Caml-list] Here comes the time Roberto Di Cosmo
2015-12-07 9:05 ` [Caml-list] ICFP 2016 Call for Papers Lindsey Kuper
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).