Scope of Journal of Functional Programming
Anything related to functional programming is of interest, including: foundations (semantics, abstract interpretation, lambda calculi, rewriting, logic, type theory, category theory); implementation (compilation, architectures, parallelism, garbage collection, I/O, debugging, profiling); linguistics (pure and impure language features, non-determinism, side effects, logical variables, relation to other programming paradigms, proofs about programs, program transformation, program synthesis, partial evaluation); applications (applications programs, practical experience, programming techniques, prototyping). Papers may describe original technical work, survey an area, or present a tutorial; and may be either short or long.
What sort of papers does Journal of Functional Programming publish?
Journal of Functional Programming publishes a variety of different sorts of paper:
Regular papers constitute the main diet. They are usually in the range 20-40 pages, but can be shorter or longer. Each paper is submitted to an Editor and is refereed. A paper may go through one or more rounds of refereeing. Included in the regular papers are ones describing the experience of applying functional programming to real problems, which is described in more detail below.
Tools and Applications covers the development of software tools using functional programming and how they may be applied.
Commercial Uses of Functional Programming includes papers explaining and describing the direct use of functional programming in industrial or commercial situations.
The Education track of Journal of Functional Programming solicits papers on innovations and experiences in functional programming education. Papers can range from describing courses and approaches, to discussing pithy examples (such as pearls), and can include tutorials. The focus should always be on pedagogic aspects, especially reporting on experiences and lessons, rather than dwelling primarily on technical aspects. Indeed, education track papers are not required to have any technical innovation at all. See also the Editorial on this track: Education Matters.
Tutorial Papers present a topic of interest to the Functional Programming community in an illuminating and accessible manner. While a tutorial paper need not make an original scientific contribution, like research papers do, it usually presents (a sequence of) ideas in a novel and insightful way. In contrast to other contributions, timing plays an important role for tutorials. An ideal tutorial explains and summarizes a series of papers on an emergent research topic before textbooks for graduate students appear and pre-empt it. Indeed, authors of tutorials may wish to think of tutorial papers as extended and refined graduate textbook proposals. Finally, an effective tutorial needs serious attending to writing, all the way from the top-level organization down to the low-level details. A well-organised tutorial introduces the research topic gradually, starting from knowledge that all first-year PhD students ought to have. It presents the ideas in a coherent manner and probably ends with a survey of how the presented ideas relate to recent results. At the same time, the writing should be so engaging that the reader will find it hard to put the paper down.
Functional Pearls are short (typically 4-10 pages), well-rounded papers describing some clever programming idea. Similarly Theoretical Pearls are short papers that deal with a specific theoretical issue of relevance to functional programming.
Book reviews, solicited by Journal of Functional Programming.
Special issues of Journal of Functional Programming have been a successful way of attracting a group of high-quality papers on a particular topic. We invite a Guest Editor or Editors to edit the issue, but one of the permanent Editors plays an "uncle" role. The Guest Editor writes and circulates an open Call for Papers, received submissions, and evaluates them with the help of referees. The Editors-in-Chief are open to proposals for Special Issues any time.
Journal of Functional Programming encourages authors of workshop and conference papers to submit enhanced versions of the same work to the journal. Typically, the version submitted to Journal of Functional Programming should contain additional discussion, examples, or proofs. Only if a workshop or conference paper is exceptionally well presented and complete is it suitable for journal publication without significant revision. If another publisher holds copyright on an earlier version of an article, the enhanced version must differ sufficiently so that the author can sign a license to publish with CUP.
Practice and experience papers
Research and papers on practice and experience sometimes receive less attention because they are perceived as possessing less academic content. So we want to remind potential authors that we have published a number of papers on this topic in the past, and have three dedicated categories: Education,Tools and Applications, and Commercial Uses of Functional Programming, which are described above. Authors are encouraged to submit papers in these categories, or on any topic related to the use of functional programming to solve real-world problems. Such papers don't have to make novel contributions to either functional programming or to the application area, but they do have to involve functional programming ideas in a central and critical way. An application may be of interest because of (rather than in spite of) being entirely straightforward, since others might hesitate to write a similar application in a functional language without evidence that it would be tractable.
Such papers should clearly summarise their contributions: - Is there a new technique -- or is the point that the application is straightforward, and no new technique is required? - Did it make a difference writing in a functional style -- or could the same application be written the same way in an imperative language? - What lessons were learned?Were there any reusable programming techniques? And so on. In general, the paper must give an account of the application area that would be regarded as well-informed, up to date, and accurate by an expert in that field.
These sorts of papers can be hard to get published in conferences, because they tend to be a little long, and because they may not report crisp new research results. Journal of Functional Programming is delighted to publish them, provided they meet the criteria above. So write on!
The Journal of Functional Programming encourages authors of workshop and conference papers to submit enhanced versions of the same work to the journal. Typically, the version submitted to Journal of Functional Programming should contain additional discussion, examples, or proofs. Only if a workshop or conference paper is exceptionally well presented and complete is it suitable for journal publication without significant revision. If another publisher holds copyright on an earlier version of an article, the enhanced version must differ sufficiently so that the author can sign a license to publish with Cambridge University Press.
Following acceptance of the paper, your final submission should include both the PDF for the paper, and a directory containing all the LaTeX source files, including any supporting style files, figures, etc.
You are also encouraged to supply supporting material for your paper which Journal of Functional Programming will make permanently accessible over the Web.
Electronic manuscripts
The publisher encourages submission of manuscripts written in LaTeX which can be used for direct typesetting. Authors can download LaTeX styles here (zip file). The site contains a user's guide and a class file which must not be edited. Associated style files should also be supplied on acceptance even though they are in general use. If you have trouble with JFP style, the publisher may be able to accept Plain TeX, or plain LaTeX or AMS TeX in article style.
On final acceptance of a paper, you will be asked to upload the TeX source code for production. Where possible, artwork and diagrams should be supplied as eps files rather than left in the TeX source. The publisher reserves the right to typeset any article by conventional means if the author's TeX code presents problems in production.
Layout of manuscripts
Manuscripts should begin with an abstract of not more than 300 words. Please avoid footnotes whenever possible. Papers should conform to a good standard of English prose: please consult a style guide such as 'The Elements of Style' by Strunk and White, Macmillan, New York. It is encouraged to present programs in one of two styles: either with identifiers in italic and keywords in bold, or entirely in fixed-width teletype font. Do not begin a sentence with a symbol or identifier name.
References
The Harvard system of references should be used. Citations are by author's surname and year of publication, and may stand either as a noun phrase (e.g., "Curry (1933)") or as a parenthetical note (e.g., "(Curry 1933)"). List references at the end of the text in alphabetical order. A typical entry is: Curry, H. B. (1933) Apparent variables from the standpoint of mathematical logic, /Ann. of Math/., *34* (2): 381-404.In the case of a reference to a conference, please give its year and location. There is no need to give the location of a publisher. For LaTeX users, information on how to correctly format references is included in the styles (zip) file above.
Illustrations
Illustrations should be supplied as ps or eps files, not as raw TeX files. They should be sized so as not to exceed the page width of the journal. Wherever possible they will be reproduced with the author's original lettering.
Figures and captions should be included as .eps files within the LaTeX source with the usual figure environment. Colour figures should be supplied in CMYK format. For more information regarding the supply of illustrations, click here.
Journal of Functional Programming's policy is to follow the spelling convention (American or British) of the author(s).
Web-accessible accompanying material for your paper
For some (but not all) papers it may be useful to accompany the paper with source code, data, proofs, or other material, in web-readable form. You are encouraged to supply such supplements, which Journal of Functional Programming will make permanently accessible over the Web. They should be considered as an element of the submission and so be subject to the review process. Find out more here.
Video Abstracts
Journal of Functional Programming invites all authors of accepted papers to submit a video abstract. The goal of such an abstract is to highlight the essential novelties and to get the viewer to read the paper. So when you design the video, ask yourself how to reach a potential viewer:
- what is the problem (area)
- what is the key idea
- what is a good graphical-visual way to bring across the idea
- where should the video refer to the paper for detail
Note: Videos may be submitted only after a paper is accepted. They are not part of the reviewing process; reviewers will continue to judge submissions solely on their scientific content.
The video can take any form that the authors would like as long as it focuses on the content of the paper. For example,
- a video may present a slide show with a voice over, like those used in conferences
- a video may show carefully edited excerpts from a conference video, though authors must respect the copyright notices on published conference videos
- the authors may produce a video specifically for JFP at their home institutions, using whatever resources are made available there.
Papers with videos will be posted in a specially advertised section (in addition to the usual entry as part of a Journal of Functional Programming volume), and the videos will be freely accessible.
Please note that in order for a video to be considered as a video abstract, but you have to supply this when sending the files to production; you can’t do it later. If you do produce a video later, for example for a later conference presentation of the journal-first publication, then we can make it available in the video gallery, but it cannot formally be a video abstract
We recommend that the video be no longer than 10 minutes, but a 15-minute conference video is acceptable provided that there are no copyright issues with sharing it.
Currently accepted formats are: mp4.