<div dir="ltr"><font face="monospace">===============================================================================<br> ACM SIGPLAN                                             CALL FOR SUBMISSIONS<br><br>                             Haskell Symposium 2023<br><br>                                Seattle, WA, USA<br>                         Fri 8 -- Sat 9 September, 2023<br><br>                 <a href="http://www.haskell.org/haskell-symposium/2023/">http://www.haskell.org/haskell-symposium/2023/</a><br><br>================================================================================<br><br>The ACM SIGPLAN Haskell Symposium 2023 will be co-located with the 2023<br>International Conference on Functional Programming (ICFP).<br><br>As with last year, Haskell'23 will use a single-track submission process. That<br>is, we will only have the regular track and no early track.<br><br>The Haskell Symposium presents original research on Haskell, discusses practical<br>experience and future development of the language, and promotes other forms of<br>declarative programming.<br><br>Topics of interest include:<br><br>  * Language design, with a focus on possible extensions and modifications of<br>    Haskell as well as critical discussions of the status quo;<br><br>  * Theory, such as formal semantics of the present language or future<br>    extensions, type systems, effects, metatheory, and foundations for program<br>    analysis and transformation;<br><br>  * Implementations, including program analysis and transformation, static and<br>    dynamic compilation for sequential, parallel, and distributed architectures,<br>    memory management, as well as foreign function and component interfaces;<br><br>  * Libraries, that demonstrate new ideas or techniques for functional<br>    programming in Haskell;<br><br>  * Tools, such as profilers, tracers, debuggers, preprocessors, and testing<br>    tools;<br><br>  * Applications, to scientific and symbolic computing, databases, multimedia,<br>    telecommunication, the web, and so forth;<br><br>  * Functional Pearls, being elegant and instructive programming examples;<br><br>  * Experience Reports, to document general practice and experience in<br>    education, industry, or other contexts;<br><br>  * Tutorials, to document how to use a particular language feature, programming<br>    technique, tool or library within the Haskell ecosystem;<br><br>  * System Demonstrations, based on running software rather than novel research<br>    results.<br><br>Regular papers should explain their research contributions in both general and<br>technical terms, identifying what has been accomplished, explaining why it is<br>significant, and relating it to previous work, and to other languages where<br>appropriate.<br><br>Experience reports and functional pearls need not necessarily report original<br>academic research results. For example, they may instead report reusable<br>programming idioms, elegant ways to approach a problem, or practical experience<br>that will be useful to other users, implementers, or researchers. The key<br>criterion for such a paper is that it makes a contribution from which other<br>Haskellers can benefit. It is not enough simply to describe a standard solution<br>to a standard programming problem, or report on experience where you used<br>Haskell in the standard way and achieved the result you were expecting.<br><br>Like an experience report and a functional pearl, tutorials should make a<br>contribution from which other Haskellers can benefit. What distinguishes a<br>tutorial is that its focus is on explaining an aspect of the Haskell language<br>and/or ecosystem in a way that is generally useful to a Haskell audience.<br>Tutorials for many such topics can be found online; the distinction here is that<br>by writing it up for formal review it will be vetted by experts and formally<br>published.<br><br>System demonstrations should summarize the system capabilities that would be<br>demonstrated. The proposals will be judged on whether the ensuing session is<br>likely to be important and interesting to the Haskell community at large,<br>whether on grounds academic or industrial, theoretical or practical, technical,<br>social or artistic. Please contact the program chair with any questions about<br>the relevance of a proposal.<br><br>If your contribution is not a research paper, please mark the title of your<br>experience report, functional pearl, tutorial or system demonstration as such,<br>by supplying a subtitle (Experience Report, Functional Pearl, Tutorial Paper,<br>System Demonstration).<br><br>Submission Details<br>==================<br><br>Formatting<br>----------<br><br>Submitted papers should be in portable document format (PDF), formatted using<br>the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with<br>the `sigplan` sub-format for ACM proceedings. For details, see:<br><br>  <a href="http://www.sigplan.org/Resources/Author/#acmart-format">http://www.sigplan.org/Resources/Author/#acmart-format</a><br><br>It is recommended to use the `review` option when submitting a paper; this<br>option enables line numbers for easy reference in reviews.<br><br>Functional pearls, experience reports, tutorials and demo proposals should be<br>labelled clearly as such.<br><br>Lightweight Double-blind Reviewing<br>----------------------------------<br><br>Haskell Symposium 2023 will use a lightweight double-blind reviewing process. To<br>facilitate this, submitted papers must adhere to two rules:<br><br> 1. Author names and institutions must be omitted, and<br> 2. References to authors' own related work should be in the third person<br>    (e.g., not "We build on our previous work" but rather "We build on the work of ").<br><br>The purpose of this process is to help the reviewers come to an initial<br>judgement about the paper without bias, not to make it impossible for them to<br>discover the authors if they were to try. Nothing should be done in the name of<br>anonymity that weakens the submission or makes the job of reviewing the paper<br>more difficult (e.g., important background references should not be omitted or<br>anonymised). In addition, authors should feel free to disseminate their ideas or<br>draft versions of their paper as they normally would. For instance, authors may<br>post drafts of their papers on the web or give talks on their research ideas.<br><br>A reviewer will learn the identity of the author(s) of a paper after a review is<br>submitted.<br><br>Page Limits<br>-----------<br><br>The length of submissions should not exceed the following limits:<br><br>Regular paper:      12 pages<br>Functional pearl:   12 pages<br>Tutorial:           12 pages<br>Experience report:   6 pages<br>Demo proposal:       2 pages<br><br>There is no requirement that all pages are used. For example, a functional pearl<br>may be much shorter than 12 pages. In all cases, the list of references is not<br>counted against these page limits.<br><br>Deadlines<br>---------<br><br>Paper submission:        1 June 2023      (Thu)<br>Notification:            4 July 2023      (Tue)<br>Camera ready:           18 July 2023      (Tue)<br><br>Deadlines are anywhere on Earth.<br><br>Submission<br>----------<br><br>Submissions must adhere to SIGPLAN's republication policy<br>(<a href="http://sigplan.org/Resources/Policies/Republication/">http://sigplan.org/Resources/Policies/Republication/</a>), and authors should be<br>aware of ACM's policies on plagiarism<br>(<a href="https://www.acm.org/publications/policies/plagiarism">https://www.acm.org/publications/policies/plagiarism</a>). Program Committee<br>members are allowed to submit papers, but their papers will be held to a higher<br>standard.<br><br>The paper submission deadline and length limitations are firm. There will be no<br>extensions, and papers violating the length limitations will be summarily<br>rejected.<br><br>Papers should be submitted through HotCRP at:<br><br>  <a href="https://haskell23.hotcrp.com/">https://haskell23.hotcrp.com/</a><br><br>Improved versions of a paper may be submitted at any point before the submission<br>deadline using the same web interface.<br><br>Supplementary material: Authors have the option to attach supplementary material<br>to a submission, on the understanding that reviewers may choose not to look at<br>it. This supplementary material should not be submitted as part of the main<br>document; instead, it should be uploaded as a separate PDF document or tarball.<br>Supplementary material should be uploaded at submission time, not by providing a<br>URL in the paper that points to an external repository. Authors can distinguish<br>between anonymised and non-anonymised supplementary material. Anonymised<br>supplementary material will be visible to reviewers immediately; non-anonymised<br>supplementary material will be revealed to reviewers only after they have<br>submitted their review of the paper and learned the identity of the author(s).<br><br>Resubmitted Papers: authors who submit a revised version of a paper that has<br>previously been rejected by another conference have the option to attach an<br>annotated copy of the reviews of their previous submission(s), explaining how<br>they have addressed these previous reviews in the present submission. If a<br>reviewer identifies him/herself as a reviewer of this previous submission and<br>wishes to see how his/her comments have been addressed, the conference chair<br>will communicate to this reviewer the annotated copy of his/her previous review.<br>Otherwise, no reviewer will read the annotated copies of the previous reviews.<br><br>Proceedings<br>===========<br><br>Accepted papers will be included in the ACM Digital Library. Their authors will<br>be required to choose one of the following options:<br><br>  - Author retains copyright of the work and grants ACM a non-exclusive<br>    permission-to-publish license (and, optionally, licenses the work with a<br>    Creative Commons license);<br><br>  - Author retains copyright of the work and grants ACM an exclusive<br>    permission-to-publish license;<br><br>  - Author transfers copyright of the work to ACM.<br><br>For more information, please see ACM Copyright Policy<br>(<a href="http://www.acm.org/publications/policies/copyright-policy">http://www.acm.org/publications/policies/copyright-policy</a>) and ACM Author<br>Rights (<a href="http://authors.acm.org/main.html">http://authors.acm.org/main.html</a>).<br><br>Accepted proposals for system demonstrations will be posted on the symposium<br>website but not formally published in the proceedings.<br><br>Publication date: The official publication date of accepted papers is the date<br>the proceedings are made available in the ACM Digital Library. This date may be<br>up to two weeks prior to the first day of the conference. The official<br>publication date affects the deadline for any patent filings related to<br>published work.<br><br>Artefacts<br>=========<br><br>Authors are encouraged to make auxiliary material (artefacts like source code,<br>test data, etc.) available with their paper. Authors can opt to have these<br>artefacts published alongside their paper in the ACM Digital Library (copyright<br>of artefacts remains with the authors). Artefacts must be included as part of<br>their submission to HotCRP and should consist of a .zip file containing the<br>artefact materials, a README explaining the contents of the artefact and how it<br>should be used, and a LICENSE file.<br><br>If an accepted paper's artefacts are made permanently available for retrieval in<br>a publicly accessible archival repository like the ACM Digital Library, that<br>paper qualifies for an Artefact badge<br>(<a href="https://www.acm.org/publications/policies/artifact-review-badging">https://www.acm.org/publications/policies/artifact-review-badging</a>).<br><br>Program Committee<br>=================<br><br>Alexander Green                 Standard Chartered, UK<br>David Thrane Christiansen       The Haskell Foundation, Denmark<br>Edsko de Vries                  Well-Typed LLP, Netherlands<br>Exequiel Rivas                  Tallinn University of Technology<br>Facundo Domínguez               Tweag<br>Florian Zuleger                 TU Vienna, Austria<br>Graham Hutton                   University of Nottingham, UK<br>Jasper Van der Jeugt            Snyk, Switzerland<br>Jennifer Paykin                 Intel, USA<br>Jesper Cockx                    Delft University of Technology, Netherlands<br>Jose Nuno Oliveira              University of Minho & INESC TEC, Portugal<br>Michael Sperber                 Active Group GmbH, Germany<br>Michel Steuwer                  University of Edinburgh, UK<br>Niki Vazou (chair)              IMDEA Software Institute, Spain<br>Rumyana Neykova                 Brunel University London, UK<br>Trevor L. McDonell (co-chair)   Utrecht University, Netherlands<br>Ugo Dal Lago                    University of Bologna, Italy & INRIA, France<br>Wen Kokke                       University of Edinburgh, UK<br>Leonidas Lampropoulos           University of Maryland, College Park, USA<br><br>If you have questions, please contact the chairs at <a href="mailto:niki.vazou@imdea.org">niki.vazou@imdea.org</a> and<br><a href="mailto:t.l.mcdonell@uu.nl">t.l.mcdonell@uu.nl</a>.<br><br>================================================================================<br></font><br></div>