- Haskell-Cafe - Haskell.org

Datakind and instance
by PICCA Frederic-Emmanuel 14 Jun '24

14 Jun '24

Hello, I have a class class HasIniConfig where getConfig ... a kind using DataKind data ProjectionType = TypeA | TypeB ... I would like to create instance for each 'TypeX But when I try to write an instance I get this error src/Hkl/Binoculars/Projections/QCustom.hs:195:23: error: • Expected a type, but ‘'QCustomProjection’ has kind ‘ProjectionType’ • In the first argument of ‘HasIniConfig’, namely ‘'QCustomProjection’ In the instance declaration for ‘HasIniConfig 'QCustomProjection’ | 195 | instance HasIniConfig 'QCustomProjection where | ^^^^^^^^^^^^^^^^^^ I should add class HasIniConfig (a :: ProjectionType) where But in that cas I can not create instance for other type, and I need to :) I would be glade if someone could explain how to all this. Thanks Frederic

2 2

POPL 2025: Call for Workshops and Co-located Events
by Ningning Xie 13 Jun '24

13 Jun '24

CALL FOR WORKSHOPS AND CO-LOCATED EVENTS POPL 2025 52nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages Sun 19 - Sat 25, January 2025 Denver, Colorado, United States https://popl25.sigplan.org The 52nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL 2025) will be held in Denver, Colorado, United States. POPL provides a forum for the discussion of fundamental principles and important innovations in the design, definition, analysis, transformation, implementation and verification of programming languages, programming systems, and programming abstractions. Events focusing on experimental and theoretical topics are welcome. Proposals are invited for workshops and other events to be co-located with POPL 2025. All co-located events are sponsored by SIGPLAN ( http://acm.org/sigplan/) Workshops should be more informal and focused than POPL itself, and include sessions that enable interaction among the workshop attendees. The preference is for one-day workshops, but other schedules can also be considered. --------------------------------------------------------------------- Submission details Deadline for submission: 26 July 2024 Notification of acceptance: 2 August 2024 A workshop proposal should provide the following information: * Name of the workshop. * Duration of the workshop. * Whether the workshop will be Conference-approved or SIGPLAN-approved (see below). * Organizers: names, affiliation, contact information, brief (100 words) biography. * A short description (150-200 words) of the topic. * Event format: workshop; type of submissions if any; review process; results dissemination. * Expected attendance and target audience. * Potential PC members - please do not contact them before the workshop is approved. * History of the workshop. * Plans for remote participation Proposals must be submitted in PDF form by email with the subject POPL 2025 Workshop Proposal: [workshop name], to the workshop co-chairs: Christoph Matheja (chmat(a)dtu.dk) and Robert Rand (rand(a)uchicago.edu) --------------------------------------------------------------------- SIGPLAN Sponsorship POPL co-located events are sponsored by SIGPLAN (http://sigplan.org/) There are two kinds of co-located events: Conference-approved (no proceedings) and SIGPLAN-approved (proceedings in the ACM Digital Library). See http://www.sigplan.org/Resources/Guidelines/Workshops/ for more information, including a full listing of prescriptions for Conference-approved and SIGPLAN-approved workshops. SIGPLAN-approved workshops must respect the SIGPLAN Diversity Policy. Proposals for SIGPLAN-approved workshops must additionally include the gender, country of affiliation, and professional status of potential PC members. See https://www.sigplan.org/Resources/Policies/Diversity/ for more details. --------------------------------------------------------------------- Selection committee All submissions will be evaluated by a committee comprising the workshops co-chairs, the general chair, and the program chair. --------------------------------------------------------------------- Further information Any questions regarding POPL 2025 co-located event proposals should be addressed to the workshops chairs Christoph Matheja (chmat(a)dtu.dk) and Robert Rand (rand(a)uchicago.edu)

1 0

Call for Papers: SPLASH 2024 Student Research Competition
by Umar Farooq 07 Jun '24

07 Jun '24

======================================================================== SPLASH 2024 Student Research Competition Call for Papers Student Research Competition will be held as part of The ACM Conference on Systems, Programming, Languages, and Applications: Software for Humanity (SPLASH'24) October 20-25, 2024, Pasadena, California, United States https://2024.splashcon.org/track/splash-2024-SRC ======================================================================== ### Important dates Submission Deadline: Mon Jul 8, 2024 Author Notification: Mon Aug 19, 2024 Camera Ready: Sun Sep 1, 2024 The ACM Student Research Competition (SRC) offers a unique opportunity for undergraduate and graduate students to present their research to a panel of judges and conference attendees at SPLASH. The SRC provides visibility and exposes up-and-coming researchers to computer science research and the research community. This competition also gives students an opportunity to discuss their research with experts in their field, get feedback, and sharpen their communication and networking skills. ### Eligibility criteria Participants must have current student status, either graduate or undergraduate, at the time of the competition. Participants in the SRC must also be current ACM (student) members. ### Prizes Winners of the three top places in each category receive prizes of $500 for the first place winner, $300 for the second place winner and $200 for the third place winner, respectively. The top three undergraduate and graduate winners receive an award medal and a one-year complimentary ACM student membership with a subscription to ACM's Digital Library. ### ACM SRC Grand Finals First place winners in each category will be invited to participate in the ACM SRC Grand Finals, an online round of competition between first-place SRC winners from different ACM conferences held in 2024. Grand Finals will be judged by an ACM-appointed panel of judges. Winners of the three top Grand Finals places in each category will receive additional prizes of $500 for the first place winner, $300 for the second place winner and $200 for the third place winner, respectively. Winners of the SRC Grand Finals are recognized at the Annual ACM Awards Banquet along with prestigious ACM award winners, including the winner of the Turing Award. ##### Review Committee Review Committee Chairs: Anders Miltner, Simon Fraser University Jiasi Shen, The Hong Kong University of Science and Technology

1 0

2nd Call for Papers: ACM Workshop on Functional Software Architecture [Deadline June 3]
by Michael Sperber 04 Jun '24

04 Jun '24

====================================================================== *** FUNARCH 2024 -- CALL FOR PAPERS *** Second ACM SIGPLAN Workshop on Functional Software Architecture - FP in the Large 6th September 2024, Milan, Italy Co-located with ICFP 2024 https://functional-architecture.org/events/funarch-2024/ ====================================================================== TIMELINE: Paper submission 3rd June 2024 Author notification 30th June 2024 Camera ready copy 18th July 2024 Workshop 6th Sept 2024 BACKGROUND: "Functional Software Architecture" refers to methods of construction and structure of large and long-lived software projects that are implemented in functional languages and released to real users, typically in industry. The goals for the workshop are: - To assemble a community interested in software architecture techniques and technologies specific to functional programming; - To identify, categorize, and document topics relevant to the field of functional software architecture; - To connect the functional programming community to the software architecture community to cross-pollinate between the two. The workshop follows on from the Functional Software Architecture open space that was held at ICFP 2022 in Slovenia. SCOPE: The workshop seeks submissions in a range of categories: - You're a member of the FP community and have thought about how to support programming in the large, for example by framing functional ideas in architectural terms or vice verse, comparing different languages in terms of their architectural capabilities, clarifying architectural roles played by formal methods, proof assistants and DSLs, or observing how functional concepts are used in other language and architecture communities. Great, submit a research paper! - You're a member of the architecture community, and have thought about how your discipline might help functional programmers, for example by applying domain-driven design, implementing hexagonal architecture, or designing self-contained systems. Excellent, submit a research paper! - You've worked on a large project using functional programming, and it's worked out well, or terribly, or a mix of both; bonus points for deriving architectural principles from your experience. Wonderful, submit an experience report! - You know a neat architectural idiom or pattern that may be useful to others developing large functional software systems. Fabulous, submit an architectural pearl! - You have something that doesn't fit the above categories, but that still relates to functional software architecture, such as something that can be written up, or that could be part of the workshop format like a panel debate or a fishbowl. Superb, submit to the open category! Research papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and architectural pearls need not necessarily report original research results. The key criterion for such papers is that they make a contribution from which others can benefit. It is not enough simply to describe a large software system, or to present ideas that are specific to a particular system. Open category submissions that are not intended for publication are not required to follow the formatting guidelines, and can submit in PDF, word or plain text format as preferred. Not knowing what kinds of submissions we will receive, we cannot be specific as to how they will be evaluated. However, submissions that seem likely to stimulate discussion around practices in functional architecture are encouraged. If you are unsure whether your contribution is suitable, or if you need any kind of help with your submission, please email the program chairs at <funarch2024(a)easychair.org>. Papers must be submitted by 3rd June 2024 using the EasyChair submission page: https://easychair.org/my/conference?conf=funarch2024 Formatting: submissions intended for publication must be in PDF format and follow the ACM SIGPLAN style guidelines, using the acmart format and the sigplan sub-format. Please use the review option when submitting, as this enables line numbers for easy reference in reviews. For further details, see SIGPLAN's author information: http://www.sigplan.org/Resources/Author/#acmart-format If your submission is not a research paper, please mark this using a subtitle (Experience Report, Architectural Pearl, Open Category). Length: submissions must adhere to the limits specified below. However, there is no requirement or expectation that all pages are used, and authors are encouraged to strive for brevity. Research papers 5 to 12+ pages Architectural pearls 5 to 12 pages Experience reports 3 to 6 pages Open category 1 to 6 pages Publication: The proceedings of FUNARCH 2024 will be published in the ACM Digital Library, and authors of accepted papers are required to agree to one of the standard ACM licensing options. Accepted papers must be presented at the workshop by one of the authors, but in special cases we may consider remote presentation. The official publication date is the date the papers 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. PROGRAM CHAIRS: Mike Sperber (Active Group, Germany) Perdita Stevens (University of Edinburgh, UK) PROGRAM COMMITTEE: Annette Bieniusa (University of Kaiserslautern) Jeffrey Young (IOG) Will Crichton (Brown University) Isabella Stilkerich (Schaeffler Technologies AG) Kiko Fernandez-Reyes (Ericsson) Ryan Scott (Galois) Satnam Singh (Groq) Facundo Dominguez (Tweag) Ilya Sergey (University of Singapore) Martin Elsman (University of Copenhagen) Benjamin Pierce (University of Pennsylvania) Matthew Flatt (University of Utah) Nada Amin (Harvard University) Richard Eisenberg (Jane Street) WORKSHOP VENUE: The workshop will be co-located with the ICFP 2024 conference at the Fiera Milano Congressi, Milan, Italy.

1 1

Exhaustive pattern match warning and GADTs
by William Yager 01 Jun '24

01 Jun '24

Hello cafe, I'm writing a bit of code with state machines that are only allowed to make certain types of transitions between certain classes of states (e.g. "ready" and "unready"). The state types have some type parameters describing which class of state it's currently in. The step functions look vaguely like `step :: state a -> input b -> state c`, with various constraints on `a`, `b`, and `c`. When `state` and `input` are GADTs, you can enforce interesting invariants about the output state, given the input state and event. This all seems to work fine, and seems to be getting me in the direction I want to go. However, I'm running into a roadblock (possibly a bug?). Take the following minimal example: {-# LANGUAGE DataKinds, GADTs #-} module Lib () where data State2 s a where State2T :: s True -> State2 s True State2F :: s False -> State2 s False data OnlyTrue s where TrueState :: OnlyTrue True example :: State2 OnlyTrue s -> () example (State2T TrueState) = () -- Comment this and get non-exhaustive pattern warning -- Uncomment this and get "Inaccessible code" warning -- example (State2F TrueState) = () There is only one possible pattern on the LHS of the equation. If I don't put the (impossible) pattern, GHC gives me a warning about missing a pattern. If I do put the impossible pattern, GHC warns me that the pattern is impossible. Indeed! So why is GHC complaining about it in the first place? I'm using GHC 9.6.5. Around 7-8 years ago, I wrote some similar code, using typeclasses to constraint GADTs, and I remember being very impressed that the completeness checker was smart enough to figure out not to complain about impossible patterns (cf the paper "GADTs meet their match"). This seems like a simpler use case than what I recall doing in the past, but the completeness checker is giving me bad warnings here. Any ideas what might be going wrong? Thanks, Will

2 2

Re: [Haskell-cafe] Issue building with ghc-9.8.2 and packages unix, directory, filepath and os-string
by Daniel Trstenjak 01 Jun '24

01 Jun '24

> The problem is that `--allow-newer` tells cabal to ignore dependencies' upper bounds > completely. If those bounds turn out to be necessary in some cases, the solver will produce a > bad build plan. Looking at the compile error of the unix package, it looks like it gets the wrong combination of filepath and os-string packages, resulting in the missing symbols. This depends on the os-string flag, either the unix package gets the older filepath package containing these symbols or the newer one without them and additionally the os-string package now containing the symbols. This handling with the os-string flag feels wrong to me and therefore cabal can‘t resolve the right dependencies. The unix 2.8.5.0 package has an upper bound for filepath of <1.5, the one with the symbols, but unix 2.8.5.1 has the lower bound filepath >1.4.100, therefore supporting the filepath packages with and without the symbols. It seems if unix 2.8.5.1 would only support the filepath package without the symbols, by having the lower bound filepath >=1.5, then cabal could work out the right dependencies. Is there a reason why the unix 2.8.5.1 does it that way?

3 2

Issue building with ghc-9.8.2 and packages unix, directory, filepath and os-string
by Daniel Trstenjak 31 May '24

31 May '24

Hi, I'm trying to get my program to compile with ghc-9.8.2. Raising the upper bounds of my dependencies I'm running into a compile error for the unix-2.8.5.1 package: [15 of 53] Compiling System.Posix.Env.PosixString ( /home/dan/sources/unix-2.8.5.1/dist-newstyle/build/x86_64-linux/ghc-9.8.2/unix-2.8.5.1/build/System/Posix/Env/PosixString.hs, /home/dan/sources/unix-2.8.5.1/dist-newstyle/build/x86_64-linux/ghc-9.8.2/unix-2.8.5.1/build/System/Posix/Env/PosixString.o, /home/dan/sources/unix-2.8.5.1/dist-newstyle/build/x86_64-linux/ghc-9.8.2/unix-2.8.5.1/build/System/Posix/Env/PosixString.dyn_o ) System/Posix/Env/PosixString.hsc:45:1: error: [GHC-87110] Could not load module ‘System.OsString.Internal.Types’. It is a member of the hidden package ‘os-string-2.0.3’. Perhaps you need to add ‘os-string’ to the build-depends in your .cabal file. It is a member of the hidden package ‘filepath-1.4.200.1’. Perhaps you need to add ‘filepath’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for. | 45 | import System.OsString.Internal.Types | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ System/Posix/Env/PosixString.hsc:47:1: error: [GHC-61948] Could not find module ‘System.OsString.Data.ByteString.Short’. Perhaps you meant System.OsString.Data.ByteString.Short (needs flag -package-id os-string-2.0.3) System.OsPath.Data.ByteString.Short (needs flag -package-id filepath-1.4.200.1) System.OsString.Data.ByteString.Short.Word16 (needs flag -package-id os-string-2.0.3) | 47 | import qualified "os-string" System.OsString.Data.ByteString.Short as B | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ System/Posix/PosixPath/FilePath.hsc:50:1: error: [GHC-61948] Could not find module ‘System.OsString.Data.ByteString.Short’. Perhaps you meant System.OsString.Data.ByteString.Short (needs flag -package-id os-string-2.0.3) System.OsPath.Data.ByteString.Short (needs flag -package-id filepath-1.4.200.1) System.OsString.Data.ByteString.Short.Word16 (needs flag -package-id os-string-2.0.3) | 50 | import "os-string" System.OsString.Data.ByteString.Short as BSS | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ System/Posix/PosixPath/FilePath.hsc:55:1: error: [GHC-87110] Could not load module ‘System.OsString.Internal.Types’. It is a member of the hidden package ‘os-string-2.0.3’. Perhaps you need to add ‘os-string’ to the build-depends in your .cabal file. It is a member of the hidden package ‘filepath-1.4.200.1’. Perhaps you need to add ‘filepath’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for. | 55 | import System.OsString.Internal.Types (PosixString(..), pattern PS) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I can get rid of this compile error and a similar one for the directory package by setting the flag os-string in my cabal.project file: constraints: unix +os-string, directory +os-string Now I'm wondering what is the right way to handle this case? Thanks for any hints! Greetings, Daniel

4 7

[ANN] Darcs 2.18.3 release
by Ben Franksen 30 May '24

30 May '24

Hello Everyone On behalf of the Darcs team, I would like to (somewhat belatedly) announce the release of Darcs 2.18.3 [1]. This is a minor bug fix release. The main issue was that Darcs failed to work on Windows when built with ghc >= 9.6. The reason was a bug in some recent versions of the directory package's 'copyFile' procedure and we adapted the dependency bounds so to avoid those versions. See [2] for the full release notes. Cheers Ben [1] https://hackage.haskell.org/package/darcs-2.18.3 [2] https://hackage.haskell.org/package/darcs-2.18.3/changelog

1 0

Re: [Haskell-cafe] [ANNOUNCE] Ajla: a new purely functional programming language
by Mikulas Patocka 29 May '24

29 May '24

On Mon, 27 May 2024, Pierpaolo Bernardi wrote: > Hello, > > the language is interesting. > > Why don't you start a mailing list to keep interested people informed about it? > > Cheers That's a great idea. I created the mailing list at https://www.freelists.org/list/ajla Mikulas

1 0

FINAL CFP: Haskell Symposium 2024
by J. Garrett Morris 29 May '24

29 May '24

Friends, The Haskell Symposium submission deadline is less than a week away, the PC is eagerly standing by, the HotCRP instance is open (thanks Mati!),... the only thing missing is you! Hope to see you in Milan. /g ---- The ACM SIGPLAN Haskell Symposium 2024 will be co-located with the 2024 International Conference on Functional Programming (ICFP). The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: - *Language design,* with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; - *Theory,* such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; - *Implementations,* including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; - *Libraries,* that demonstrate new ideas or techniques for functional programming in Haskell; - *Tools,* such as profilers, tracers, debuggers, preprocessors, and testing tools; - *Applications,* to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; - *Functional Pearls,* being elegant and instructive programming examples; - *Experience Reports,* to document general practice and experience in education, industry, or other contexts; - *Tutorials,* to document how to use a particular language feature, programming technique, tool or library within the Haskell ecosystem; - *System Demonstrations,* based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. *New this year*, talk proposals need not be full-length, and should report work in progress relevant to Haskell language design, theory, tools, or applications. Talk proposals will be evaluated by the PC for novelty and relevance to the Haskell community, but are not expected to include finished results. Talk proposals will not be distributed to attendees, but authors of talk proposals may provide links to materials to be included on the program. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. Like an experience report and a functional pearl, tutorials should make a contribution from which other Haskellers can benefit. What distinguishes a tutorial is that its focus is on explaining an aspect of the Haskell language and/or ecosystem in a way that is generally useful to a Haskell audience. Tutorials for many such topics can be found online; the distinction here is that by writing it up for formal review it will be vetted by experts and formally published. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. If your contribution is not a research paper, please mark the title of your experience report, functional pearl, tutorial or system demonstration as such, by supplying a subtitle (Talk Proposal, Experience Report, Functional Pearl, Tutorial Paper, System Demonstration). Submission Details Formatting Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the acmart format, with the sigplan sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the review option when submitting a paper; this option enables line numbers for easy reference in reviews. Talk proposals, functional pearls, experience reports, tutorials and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing Haskell Symposium 2024 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: - Author names and institutions must be omitted, and - 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 reviewers come to an initial judgment 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. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits The length of submissions should not exceed the following limits: - *Regular paper:* 12 pages - *Talk proposals:* 6 pages - *Functional pearl:* 12 pages - *Tutorial:* 12 pages - *Experience report:* 6 pages - *Demo proposal:* 2 pages There is no requirement that all pages are used. For example, a good talk proposal might be two pages, and a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines - *Paper submission:* 3 June 2024 (Mon) - *Notification:* 5 July 2024 (Fri) - *Camera-ready Deadline:* 18 July 2024 (Thu) Deadlines are end of day Anywhere on Earth (UTC-12) <https://www.timeanddate.com/time/zones/aoe>. Submission Submissions must adhere to SIGPLAN’s republication policy <http://sigplan.org/Resources/Policies/Republication/>, and authors should be aware of ACM’s policies on plagiarism <https://www.acm.org/publications/policies/plagiarism>. Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell24.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. *Supplementary material:* Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors can distinguish between anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). *Resubmitted Papers:* authors who submit a revised version of a paper that has previously been rejected by another conference 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 conference 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. Proceedings Accepted papers will be included in the ACM Digital Library. Their authors will be required to choose one of the following options: - Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license (and, optionally, licenses the work with a Creative Commons license); - Author retains copyright of the work and grants ACM an exclusive permission-to-publish license; - Author transfers copyright of the work to ACM. For more information, please see ACM Copyright Policy <http://www.acm.org/publications/policies/copyright-policy> and ACM Author Rights <http://authors.acm.org/main.html>. Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. *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. Artifacts Authors of accepted papers are encouraged to make auxiliary material (artifacts like source code, test data, etc.) available with their paper. They can opt to have these artifacts published alongside their paper in the ACM Digital Library (copyright of artifacts remains with the authors). If an accepted paper’s artifacts are made permanently available for retrieval in a publicly accessible archival repository like the ACM Digital Library, that paper qualifies for an Artifacts Available badge ( https://www.acm.org/publications/policies/artifact-review-badging#available) Applications for such a badge can be made after paper acceptance and will be reviewed by the PC chair.

1 0