<div dir="ltr"><div style="color:rgb(59,59,59);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;line-height:18px;white-space:pre"><div>                   PACMPL Volume 7, Issue ICFP 2025</div><br><div>                           Call for Papers</div><br><div>       Accepted papers to be invited for presentation at</div><div> </div><div>The 30th ACM SIGPLAN International Conference on Functional Programming</div><div>                         October 12-18, 2025</div><div>                              Singapore</div><br><div>                      <a href="https://icfp25.sigplan.org/">https://icfp25.sigplan.org/</a></div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### Important Dates and Deadlines</span></div><br><div>Paper Submissions: February 27, 2025</div><div>Author Response: April 28 - May 1, 2025</div><div>Notifications of Acceptance: May 23, 2025</div><br><div>All deadlines are Anywhere on Earth (AoE).</div><br><div>Conference dates: October 12-18, 2025</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### New This Year</span></div><br><div>For the first time, ICFP will be co-located with SPLASH!</div><div><a href="https://conf.researchr.org/home/icfp-splash-2025">https://conf.researchr.org/home/icfp-splash-2025</a> </div><br><div>Note that the conference will be held in October this year, instead of</div><div>September. The conference dates are October 12-18, 2025. </div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### Scope</span></div><br><div>PACMPL issue ICFP 2025 seeks original papers on the art and science of</div><div>functional programming. Submissions are invited on all topics from principles to</div><div>practice, from foundations to features, and from abstraction to application. The</div><div>scope includes all languages that encourage functional programming, including</div><div>both purely applicative and imperative languages, as well as languages with</div><div>objects, concurrency, or parallelism. Topics of interest include (but are not</div><div>limited to):</div><br><div><span style="color:rgb(4,81,165)">*</span> Language Design: concurrency, parallelism, and distribution; modularity;</div><div>  components and composition; meta-programming; macros; pattern matching; type</div><div>  systems; type inference; dependent types; effect types; gradual types;</div><div>  refinement types; session types; interoperability; domain-specific languages;</div><div>  imperative programming; object-oriented programming; logic programming;</div><div>  probabilistic programming; reactive programming; generic programming;</div><div>  bidirectional programming.</div><br><div><span style="color:rgb(4,81,165)">*</span> Implementation: abstract machines; virtual machines; interpretation;</div><div>  compilation; compile-time and run-time optimisation; garbage collection and</div><div>  memory management; runtime systems; multi-threading; exploiting parallel</div><div>  hardware; interfaces to foreign functions, services, components, or low-level</div><div>  machine resources.</div><br><div><span style="color:rgb(4,81,165)">*</span> Software-Development Techniques: algorithms and data structures; design</div><div>  patterns; specification; verification; validation; proof assistants;</div><div>  debugging; testing; tracing; profiling; build systems; program synthesis.</div><br><div><span style="color:rgb(4,81,165)">*</span> Foundations: formal semantics; lambda calculus; program equivalence;</div><div>  rewriting; type theory; logic; category theory; computational effects;</div><div>  continuations; control; state; names and binding; program verification.</div><br><div><span style="color:rgb(4,81,165)">*</span> Analysis and Transformation: control flow; data flow; abstract interpretation;</div><div>  partial evaluation; program calculation.</div><br><div><span style="color:rgb(4,81,165)">*</span> Applications: symbolic computing; formal-methods tools; artificial</div><div>  intelligence; systems programming; distributed systems and web programming;</div><div>  hardware design; databases; scientific and numerical computing; graphical user</div><div>  interfaces; graphics and multimedia; GPU programming; scripting; system</div><div>  administration; security.</div><br><div><span style="color:rgb(4,81,165)">*</span> Education: teaching introductory programming; mathematical proof; algebra.</div><br><div>Submissions will be evaluated according to their relevance, correctness,</div><div>significance, originality, and clarity. Each submission should explain its</div><div>contributions in both general and technical terms, clearly identifying what has</div><div>been accomplished, explaining why it is significant, and comparing it with</div><div>previous work. The technical content should be accessible to a broad audience.</div><br><div>PACMPL issue ICFP 2025 also welcomes submissions in two separate categories —</div><div>Functional Pearls and Experience Reports — that must be marked as such when</div><div>submitted and that need not report original research results. Detailed</div><div>guidelines on both categories are given at the end of this call.</div><br><div>In an effort to achieve a balanced, diverse program, each author may be listed</div><div>as a (co)author on a maximum of four submissions. Authors who require financial</div><div>support to attend the conference can apply for PAC funding</div><div>(<a href="http://www.sigplan.org/PAC/">http://www.sigplan.org/PAC/</a>).</div><br><div>The General Chair and PC Chair may not submit papers. PC members (other than the</div><div>PC Chair) may submit papers.</div><br><div>Please contact the Program Chair if you have questions or are concerned about</div><div>the appropriateness of a topic.</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### Full Double-Blind Reviewing Process</span></div><br><div>ICFP 2025 will use a full double-blind reviewing process (similar to the one</div><div>used for ICFP 2024 but different from the lightweight double-blind process used</div><div>in previous years). This means that identities of authors will not be made</div><div>visible to reviewers until after conditional-acceptance decisions have been</div><div>made, and then only for the conditionally-accepted papers. The use of full</div><div>double-blind reviewing has several consequences for authors.</div><br><div><span style="font-style:italic">*Submissions*</span>: Authors must omit their names and institutions from their paper</div><div>submissions. In addition, references to authors’ own prior work should be in the</div><div>third person (e.g., not "We build on our previous work ..." but rather "We build</div><div>on the work of ...").</div><br><div><span style="font-style:italic">*Supplementary material*</span>: Authors must fully anonymize any supplementary</div><div>material (see below). Links to supplementary material on external websites are</div><div>not permitted.</div><br><div><span style="font-style:italic">*Author response*</span>: In responding to reviews, authors should not say anything</div><div>that reveals their identity, since author identities will not be revealed to</div><div>reviewers at that stage of the reviewing process.</div><br><div><span style="font-style:italic">*Dissemination of work under submission*</span>: Authors are welcome to disseminate</div><div>their ideas and post draft versions of their paper(s) on their personal website,</div><div>institutional repository, or arXiv (reviewers will be asked to turn off arXiv</div><div>notifications during the review period). But authors should not take steps that</div><div>would almost certainly reveal their identities to members of the Program</div><div>Committee, e.g., directly contacting PC members or publicizing the work on</div><div>widely-visible social media or major mailing lists used by the community.</div><br><div>The purpose of the above restrictions is to help the Program Committee and</div><div>external reviewers come to a judgment about the paper without bias, not to make</div><div>it impossible for them to discover the authors’ identities if they were to try.</div><div>In particular, nothing should be done in the name of anonymity that weakens the</div><div>quality of the submission. However, there are occasionally cases where adhering</div><div>to the above restrictions is truly difficult or impossible for one reason or</div><div>another. In such cases, the authors should contact the Program Chair to discuss</div><div>the situation and how to handle it. The FAQ on Double-Blind Reviewing</div><div>(<a href="https://popl24.sigplan.org/track/POPL-2024-popl-research-papers#FAQ-on-Double-Blind-Reviewing">https://popl24.sigplan.org/track/POPL-2024-popl-research-papers#FAQ-on-Double-Blind-Reviewing</a>)</div><div>addresses many common scenarios and answers many common questions about this</div><div>topic. But there remain many grey areas and trade-offs. If you have any doubts</div><div>about how to interpret the double-blind rules or you encounter a complex case</div><div>that is not clearly covered by the FAQ, please contact the Program Chair for</div><div>guidance.</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### Preparation of submissions</span></div><br><div><span style="font-style:italic">*Deadline*</span>: The deadline for submissions is Thursday, 27 February, 2025,</div><div>Anywhere on Earth (<a href="https://www.timeanddate.com/time/zones/aoe">https://www.timeanddate.com/time/zones/aoe</a>). This deadline</div><div>will be strictly enforced.</div><br><div><span style="font-style:italic">*Formatting*</span>: Submissions must be in PDF format, printable in black and white on</div><div>US Letter sized paper and interpretable by common PDF tools. All submissions</div><div>must adhere to the "ACM Small" template that is available (in both LaTeX and</div><div>Word formats) from <a href="https://www.acm.org/publications/authors/submissions">https://www.acm.org/publications/authors/submissions</a>.</div><br><div>Please download the latest version of the ACM style from</div><div><a href="https://www.acm.org/publications/authors/submissions">https://www.acm.org/publications/authors/submissions</a>, since the citation format</div><div>has recently been changed.</div><br><div>See also PACMPL’s Information and Guidelines for Authors at</div><div><a href="https://pacmpl.acm.org/authors.cfm">https://pacmpl.acm.org/authors.cfm</a>.</div><br><div>There is a limit of 25 pages for a full paper or Functional Pearl and 12 pages</div><div>for an Experience Report; in either case, the bibliography and an optional</div><div>clearly marked appendix will not be counted against these limits. Submissions</div><div>that exceed the page limits or, for other reasons, do not meet the requirements</div><div>for formatting, will be summarily rejected.</div><br><div><span style="font-style:italic">*Submission*</span>: Submissions will be accepted at <a href="https://icfp25.hotcrp.com/">https://icfp25.hotcrp.com/</a></div><br><div>Improved versions of a paper may be submitted at any point before the submission</div><div>deadline using the same web interface.</div><br><div><span style="font-style:italic">*Author Response Period*</span>: Authors will have a 96-hour period, starting at 00:00</div><div>(midnight) AOE on Monday, 28 April, 2025, to read reviews and respond to them.</div><br><div><span style="font-style:italic">*Appendix and Supplementary Material*</span>: Authors have the option to include a</div><div>clearly marked appendix and/or to attach supplementary material to a submission,</div><div>on the understanding that reviewers may choose not to look at such an appendix</div><div>or supplementary material. Supplementary material may be uploaded as a separate</div><div>PDF document or tarball. Any supplementary material must be uploaded at</div><div>submission time, not by providing a URL in the paper that points to an external</div><div>repository. All supplementary material must be anonymised.</div><br><div><span style="font-style:italic">*Authorship Policies*</span>: All submissions are expected to comply with the ACM</div><div>Policies for Authorship that are detailed at</div><div><a href="https://www.acm.org/publications/authors/information-for-authors">https://www.acm.org/publications/authors/information-for-authors</a>.</div><br><div><span style="font-style:italic">*Republication Policies*</span>: Each submission must adhere to SIGPLAN’s republication</div><div>policy, as explained on the web at</div><div><a href="http://www.sigplan.org/Resources/Policies/Republication">http://www.sigplan.org/Resources/Policies/Republication</a>.</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### Review Process</span></div><br><div>This section outlines the two-stage process with double-blind reviewing that</div><div>will be used to select papers for PACMPL issue ICFP 2025. Like last year, ICFP</div><div>2025 will adapt a full double-blind reviewing process. More information see</div><div>below.</div><br><div>ICFP 2025 will have an Associate Chair who will help the PC Chair monitor</div><div>reviews, solicit external expert reviews for submissions when there is not</div><div>enough expertise on the committee, and facilitate reviewer discussions.</div><br><div>ICFP 2025 will employ a two-stage review process. The first stage in the review</div><div>process will assess submitted papers using the criteria stated above and will</div><div>allow for feedback and input on initial reviews through the author response</div><div>period mentioned previously. As a result of the review process, a set of papers</div><div>will be conditionally accepted and all other papers will be rejected. Authors</div><div>will be notified of these decisions on 23 May, 2025.</div><br><div>Authors of conditionally accepted papers will be provided with committee reviews</div><div>along with a set of mandatory revisions. By 12 June, 2025, the authors should</div><div>provide a second revised submission. The second and final reviewing phase</div><div>assesses whether the mandatory revisions have been adequately addressed by the</div><div>authors and thereby determines the final accept/reject status of the paper. The</div><div>intent and expectation is that the mandatory revisions can feasibly be addressed</div><div>within three weeks.</div><br><div>The second submission should clearly identify how the mandatory revisions were</div><div>addressed. To that end, the second submission must be accompanied by a cover</div><div>letter mapping each mandatory revision request to specific parts of the paper.</div><div>The cover letter will facilitate a quick second review, allowing for</div><div>confirmation of final acceptance within two weeks. Conversely, the absence of a</div><div>cover letter will be grounds for the paper’s rejection.</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### Information for Authors of Accepted Papers</span></div><br><div><span style="color:rgb(4,81,165)">*</span> As a condition of acceptance, final versions of all papers must adhere to the</div><div>  ACM Small format. The page limit for the final versions of papers will be</div><div>  increased by two pages to help authors respond to reviewer comments and</div><div>  mandatory revisions: 27 pages plus bibliography for a regular paper or</div><div>  Functional Pearl, 14 pages plus bibliography for an Experience Report.</div><br><div><span style="color:rgb(4,81,165)">*</span> Authors of accepted submissions will be required to agree to one of the three</div><div>  ACM licensing options, one of which is Creative Commons CC-BY publication;</div><div>  this is the option recommended by the PACMPL editorial board. A reasoned</div><div>  argument in favour of this option can be found in the article Why CC-BY?</div><div>  published by OASPA, the Open Access Scholarly Publishers Association. The</div><div>  other options are copyright transfer to ACM or retaining copyright but</div><div>  granting ACM exclusive publication rights.</div><br><div><span style="color:rgb(4,81,165)">*</span> PACMPL is a Gold Open Access journal, and authors are encouraged to publish</div><div>  their work under a CC-BY license. Gold Open Access guarantees permanent free</div><div>  online access to the definitive version in the ACM Digital Library, and the</div><div>  recommended CC-BY option also allows anyone to copy and distribute the work</div><div>  with attribution. Gold Open Access has been made possible by generous funding</div><div>  through ACM SIGPLAN, which will cover all open access costs in the event</div><div>  authors cannot. Authors who can cover the costs may do so by paying an Article</div><div>  Processing Charge (APC). PACMPL, SIGPLAN, and ACM Headquarters are committed</div><div>  to exploring routes to making Gold Open Access publication both affordable and</div><div>  sustainable.</div><br><div><span style="color:rgb(4,81,165)">*</span> ACM Author-Izer is a unique service that enables ACM authors to generate and</div><div>  post links on either their home page or institutional repository for visitors</div><div>  to download the definitive version of their articles from the ACM Digital</div><div>  Library at no charge. Downloads through Author-Izer links are captured in</div><div>  official ACM statistics, improving the accuracy of usage and impact</div><div>  measurements. Consistently linking to the definitive version of an ACM article</div><div>  should reduce user confusion over article versioning. After an article has</div><div>  been published and assigned to the appropriate ACM Author Profile pages,</div><div>  authors should visit <a href="http://www.acm.org/publications/acm-author-izer-service">http://www.acm.org/publications/acm-author-izer-service</a></div><div>  to learn how to create links for free downloads from the ACM DL.</div><br><div><span style="color:rgb(4,81,165)">*</span> The official publication date is the date the papers are made available in the</div><div>  ACM Digital Library. This date may be up to two weeks prior to the first day</div><div>  of the conference. The official publication date affects the deadline for any</div><div>  patent filings related to published work.</div><br><div><span style="color:rgb(4,81,165)">*</span> Authors of each accepted submission are invited to attend and be available for</div><div>  the presentation of that paper at the conference. The schedule for</div><div>  presentations will be determined and shared with authors after the full</div><div>  program has been selected.</div><br><div><span style="font-style:italic">*ORCID*</span>: ORCID provides a persistent digital identifier (an ORCID iD) that you</div><div>own and control, and that distinguishes you from every other researcher:</div><div><a href="https://orcid.org/">https://orcid.org/</a>. ACM now require an ORCID iD for every author of a paper, not</div><div>just the corresponding author. So, the author who is filling out the permission</div><div>form should make sure they have the ORCID iDs for all of their coauthors before</div><div>filling out the form. Any authors who do not yet have an ORCID iD can go to</div><div><a href="https://orcid.org/register">https://orcid.org/register</a> to have one assigned.</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### Artifact Evaluation</span></div><br><div>Authors of papers that are conditionally accepted in the first phase of the</div><div>review process will be encouraged (but not required) to submit supporting</div><div>materials for Artifact Evaluation. These items will then be reviewed by an</div><div>Artifact Evaluation Committee, separate from the paper Review Committee, whose</div><div>task is to assess how the artifacts support the work described in the associated</div><div>paper. Papers that go through the Artifact Evaluation process successfully will</div><div>receive a seal of approval printed on the papers themselves. Authors of accepted</div><div>papers will be encouraged to make the supporting materials publicly available</div><div>upon publication of the papers, for example, by including them as "source</div><div>materials" in the ACM Digital Library. An additional seal will mark papers whose</div><div>artifacts are made available, as outlined in the ACM guidelines for artifact</div><div>badging.</div><br><div>Participation in Artifact Evaluation is voluntary and will not influence the</div><div>final decision regarding paper acceptance.</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### Special categories of papers</span></div><br><div>In addition to research papers, PACMPL issue ICFP solicits two kinds of papers</div><div>that do not require original research contributions: Functional Pearls, which</div><div>are full papers, and Experience Reports, which are limited to half the length of</div><div>a full paper. Authors submitting such papers should consider the following</div><div>guidelines.</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### Functional Pearls</span></div><br><div>A Functional Pearl is an elegant essay about something related to functional</div><div>programming. Examples include, but are not limited to:</div><br><div><span style="color:rgb(4,81,165)">*</span> a new and thought-provoking way of looking at an old idea</div><div><span style="color:rgb(4,81,165)">*</span> an instructive example of program calculation or proof</div><div><span style="color:rgb(4,81,165)">*</span> a nifty presentation of an old or new data structure</div><div><span style="color:rgb(4,81,165)">*</span> an interesting application of functional programming techniques</div><div><span style="color:rgb(4,81,165)">*</span> a novel use or exposition of functional programming in the classroom</div><br><div>While pearls often demonstrate an idea through the development of a short</div><div>program, there is no requirement or expectation that they do so. Thus, they</div><div>encompass the notions of theoretical and educational pearls.</div><br><div>Functional Pearls are valued as highly and judged as rigorously as ordinary</div><div>papers, but using somewhat different criteria. In particular, a pearl is not</div><div>required to report original research, but, it should be concise, instructive,</div><div>and entertaining. A pearl is likely to be rejected if its readers get bored, if</div><div>the material gets too complicated, if too much-specialised knowledge is needed,</div><div>or if the writing is inelegant. The key to writing a good pearl is polishing.</div><br><div>A submission that is intended to be treated as a pearl must be marked as such on</div><div>the submission web page and should contain the words "Functional Pearl"</div><div>somewhere in its title or subtitle. These steps will alert reviewers to use the</div><div>appropriate evaluation criteria. Pearls will be combined with ordinary papers,</div><div>however, for the purpose of computing the conference’s acceptance rate.</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### Experience Reports</span></div><br><div>The purpose of an Experience Report is to describe the experience of using</div><div>functional programming in practice, whether in industrial application, tool</div><div>development, programming education, or any other area.</div><br><div>Possible topics for an Experience Report include, but are not limited to:</div><br><div><span style="color:rgb(4,81,165)">*</span> insights gained from real-world projects using functional programming</div><div><span style="color:rgb(4,81,165)">*</span> comparison of functional programming with conventional programming in the</div><div>  context of an industrial project or a university curriculum</div><div><span style="color:rgb(4,81,165)">*</span> project-management, business, or legal issues encountered when using</div><div>  functional programming in a real-world project</div><div><span style="color:rgb(4,81,165)">*</span> curricular issues encountered when using functional programming in education</div><div><span style="color:rgb(4,81,165)">*</span> real-world constraints that created special challenges for an implementation</div><div>  of a functional language or for functional programming in general</div><br><div>An Experience Report is distinguished from a normal PACMPL issue ICFP paper by</div><div>its title, by its length, and by the criteria used to evaluate it.</div><br><div><span style="color:rgb(4,81,165)">*</span> Both in the papers and in any citations, the title of each accepted Experience</div><div>  Report must end with the words "(Experience Report)" in parentheses. The</div><div>  acceptance rate for Experience Reports will be computed and reported</div><div>  separately from the rate for ordinary papers.</div><div><span style="color:rgb(4,81,165)">*</span> Experience Report submissions can be at most 12 pages long, excluding</div><div>  bibliography.</div><div><span style="color:rgb(4,81,165)">*</span> Each accepted Experience Report will be presented at the conference, but</div><div>  depending on the number of Experience Reports and regular papers accepted,</div><div>  authors of Experience Reports may be asked to give shorter talks.</div><div><span style="color:rgb(4,81,165)">*</span> Because the purpose of Experience Reports is to enable our community to</div><div>  understand the application of functional programming, an acceptable Experience</div><div>  Report need not add to the body of knowledge of the functional-programming</div><div>  community by presenting novel results or conclusions. It is sufficient if the</div><div>  report describes an illuminating experience with functional programming, or</div><div>  provides evidence for a clear thesis about the use of functional programming.</div><div>  The experience or thesis must be relevant to ICFP, but it need not be novel.</div><br><div>The review committee will accept or reject Experience Reports based on whether</div><div>they judge the paper to illuminate some aspect of the use of functional</div><div>programming. Anecdotal evidence will be acceptable provided it is well-argued</div><div>and the author explains what efforts were made to gather as much evidence as</div><div>possible. Typically, papers that show how functional programming was used are</div><div>more convincing than papers that say only that functional programming was used.</div><div>It can be especially effective to present comparisons of the situations before</div><div>and after the experience described in the paper, but other kinds of evidence</div><div>would also make sense, depending on context. Experience drawn from a single</div><div>person’s experience may be sufficient, but more weight will be given to evidence</div><div>drawn from the experience of groups of people.</div><br><div>An Experience Report should be short and to the point. For an industrial</div><div>project, it should make a claim about how well functional programming worked and</div><div>why; for a pedagogy paper, it might make a claim about the suitability of a</div><div>particular teaching style or educational exercise. Either way, it should produce</div><div>evidence to substantiate the claim. If functional programming worked in this</div><div>case in the same ways it has worked for others, the paper need only summarise</div><div>the results — the main part of the paper should discuss how well it worked and</div><div>in what context. Most readers will not want to know all the details of the</div><div>experience and its implementation, but the paper should characterise it and its</div><div>context well enough so that readers can judge to what degree this experience is</div><div>relevant to their own circumstances. The paper should take care to highlight any</div><div>unusual aspects; specifics about the experience are more valuable than</div><div>generalities about functional programming.</div><br><div>If the paper not only describes experience but also presents new technical</div><div>results, or if the experience refutes cherished beliefs of the</div><div>functional-programming community, it may be better to submit it as a full paper,</div><div>which will be judged by the usual criteria of novelty, originality, and</div><div>relevance. The Program Chair will be happy to advise on any concerns about which</div><div>category to submit to.</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### About PACMPL</span></div><br><div>Proceedings of the ACM on Programming Languages (PACMPL <a href="https://pacmpl.acm.org/">https://pacmpl.acm.org/</a>)</div><div>is a Gold Open Access journal publishing research on all aspects of programming</div><div>languages, from design to implementation and from mathematical formalisms to</div><div>empirical studies. Each issue of the journal is devoted to a particular subject</div><div>area within programming languages and will be announced through publicised Calls</div><div>for Papers, like this one.</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### ICFP Organizers</span></div><br><div>General Chair:</div><div>  Ilya Sergey (NUS)</div><div>Program Chair:</div><div>  Dominique Devriese (KU Leuven)</div><div>Associate Program Chair:</div><div>  Peter Thiemann (University of Freiburg)</div><div>Workshops Co-Chairs:</div><div>  Ben Greenman (University of Utah)</div><div>  Chandrakana Nandi (Certora)</div><div>Artifact Evaluation Co-Chairs:</div><div>  Benoît Montagu (INRIA)</div><div>  Lionel Parreaux (HKUST)</div><div>Industrial Relations Chair:</div><div>  Daniel Winograd-Cort (Nectry Inc.)</div><div>Student Volunteer Chair:</div><div>  Joe Watt (Institute for Infocomm Research, A*STAR)</div><div>SRC Co-Chair:</div><div>  Kuen-Bang Hou (Favonia) (University of Minnesota)</div><div>Publicity Chair:</div><div>  Sam Westrick (NYU)</div><div>Diversity Co-Chairs:</div><div>  Alejandro Russo (Chalmers, DPella)</div><div>  KC Sivaramakrishnan (Tarides, IIT Madras)</div><div>Web Chair:</div><div>  Jules Jacobs (Cornell)</div><div>Doctoral Symposium Chair:</div><div>  Conrad Watt (Nanyang Technological University)</div><div>Programming Contest Organizer:</div><div>  Liam O'Connor (Australian National University)</div><div>SIGPLAN Conference Manager:</div><div>  Neringa Young</div></div></div>