- Haskell-Cafe - Haskell.org

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

Re: [Haskell-cafe] GHC release series adoption rates
by amindfv＠mailbox.org 29 May '24

29 May '24

On Tue, May 28, 2024 at 09:30:46PM +0100, Simon Peyton Jones wrote: > [...] In particular, it'd be great to have some telemetry. Telemetry is a complex > issue -- but we now have some very well-informed colleagues: the team at > Scarf. So maybe we'll get some basic data before long, which would be a > big step forward. (We'd expect to be transparent about that too of course!) Respectfully, "we'd expect to be transparent about that" already feels like a violated promise. I did not know until this email that Haskell.org had engaged a telemetry gateway using "zero-cookie tracking pixels" for "meticulous tracking of visitor patterns" to engage with their "previously anonymous audience"! (Quotes from https://about.scarf.sh/post/haskell-org-bridging-the-gap-between-language-i… and from the homepage and FAQ.) I'd expect the primary purpose of a language homepage, language asset distribution, etc. is to provide software to those who would use it. To use tarball distribution to "understand where in the funnel your open source users are," "transforming anonymous downloads, web traffic, and usage into company profiles and journeys," etc. feels like a deep scammy repurposing of our central resource (Haskell.org) for surveillance and marketing purposes. They explicitly focus on, for example, using IP addresses for "Identifying which companies are using a particular package." And as far as I can tell, this data is going to Scarf the (multimillion dollar, VC-funded) company too. This is bad. I want to reiterate my deep respect for the project, but jeez - this is not a good path to go down. Thanks, Tom

1 0

[ANNOUNCE] Ajla: a new purely functional programming language
by Mikulas Patocka 27 May '24

27 May '24

Hi I'd like to announce the release of Ajla - a new purely functional programming language that looks like traditional procedural languages. If you are interested, see https://www.ajla-lang.cz/ Mikulas

3 3

PLMW@ICFP'24: Call for Participation (travel funding application by June 21)
by Ningning Xie 24 May '24

24 May '24

ACM SIGPLAN Programming Languages Mentoring Workshop (PLMW) at ICFP 24, Milan, Italy Workshop: Monday, September 2, 2024 Website: https://icfp24.sigplan.org/home/PLMW-ICFP-2024 PLMW is a workshop co-located with ICFP 2024 (the International Conference on Functional Programming) in Milan, Italy, from September 2-7. The purpose of this mentoring workshop is to encourage graduate students and senior undergraduate students to pursue careers in programming language research. This workshop will bring together world leaders in programming languages research and teaching from academia and industry to help students imagine how they might contribute to our research community. Topics will range from the abstract (e.g., what is PL research and how does one become involved in it) to the concrete (e.g., how to navigate an academic conference, how to pick a research area) as well as technical talks on cutting-edge topics. We especially encourage women and underrepresented minority students, and people with disabilities to attend PLMW. This workshop is part of the activities surrounding ICFP, and takes place the day before the main conference. One goal of the workshop is to make the ICFP conference more accessible to newcomers. We hope that participants will stay through the entire conference. Note that ICFP and PLMW are planned to be largely in-person events. While we recognize that travel to conferences is not easy for everyone, we do hope you will be able to join us in person to get the most out of the conference and its community-building aspects. A number of sponsors have generously donated scholarship funds for qualified students to attend PLMW. These scholarships can cover expenses (airfare, hotel, and registration fees) for attendance at both the workshop and the ICFP conference. Students attending this year will get one year free student membership of SIGPLAN, unless they prefer to opt out during their application. The workshop registration is open to all. Students with alternative sources of funding are welcome as well. —-------------------------------------------------------------- APPLICATION FOR PLMW TRAVEL FUNDING For full consideration for scholarship funding, please apply at the link below by June 21, AoE. We will notify accepted attendees in a rolling fashion until all funding is committed. The application can be accessed at the following URL (Apply by June 21, 2024 AOE for full consideration!): https://forms.gle/vC6udnMWRvvAczPR6

1 0

CGO'25 - Call for Papers
by Luisa Cicolini 22 May '24

22 May '24

IEEE/ACM International Symposium on Code Generation and Optimization (CGO<https://2025.cgo.org/>) Co-located with PPoPP<https://conf.researchr.org/series/PPoPP>, HPCA<https://hpca-conf.org/2025/> and CC<https://conf.researchr.org/series/CC> Las Vegas, USA The International Symposium on Code Generation and Optimization (CGO’25) will be held in Las Vegas, USA. CGO is the premier venue to bring together researchers and practitioners working at the interface of hardware and software on a wide range of optimization and code generation techniques and related issues. The conference spans the spectrum from purely static to fully dynamic approaches, and from pure software-based methods to specific architectural features and support for code generation and optimization. ________________________________ CGO now uses two submissions per year. This follows the model established by other conferences in our field in recent years, such as ASPLOS and OOPSLA. Papers submitted to the first round can either be directly accepted, rejected, or invited to submit a revised version of the paper to the second round. For papers invited to submit a revised version, authors will be given a list of revisions that should be acted on to improve the paper. We will make every effort to ensure that the revised paper is reviewed by the same referees, who will assess whether the revisions are satisfactory. If so, the paper will be accepted. If a paper is rejected, the authors may still submit a revised version in a subsequent round, which will be treated as a new submission. ________________________________ First Submission Deadline * Paper Submission: May 30, 2024 * Author Rebuttal Period: July 9-11, 2024 * Paper Notification: July 22, 2024 Second Submission Deadline * Paper Submission: September 12, 2024 * Author Rebuttal Period: October 22 - 24, 2024 * Paper Notification: November 4, 2024 Contacts: * Hugh Leather - Meta – hleather(a)meta.com<mailto:hleather@meta.com> * P. (Saday) Sadayappan – University of Utah – saday(a)cs.utah.edu<mailto:saday@cs.utah.edu> ________________________________ Topics Original contributions are solicited on, but not limited to, the following topics: * Code Generation, Translation, Transformation, and Optimization for performance, energy, virtualization, portability, security, or reliability concerns, and architectural support * Efficient execution of dynamically typed and higher-level languages * Optimization and code generation for emerging programming models, platforms, domain-specific languages * Dynamic/static, profile-guided, feedback-directed, and machine learning-based optimization * Static, Dynamic, and Hybrid Analysis for performance, energy, memory locality, throughput or latency, security, reliability, or functional debugging * Program characterization methods * Profiling and instrumentation techniques; architectural support * Novel and efficient tools * Compiler design, practice and experience * Compiler abstraction and intermediate representations * Vertical integration of language features, representations, optimizations, and runtime support for parallelism * Solutions that involve cross-layer (HW/OS/VM/SW) design and integration * Deployed dynamic/static compiler and runtime systems for general purpose, embedded system and Cloud/HPC platforms * Parallelism, heterogeneity, and reconfigurable architectures * Optimizations for heterogeneous or specialized targets, GPUs, SoCs, CGRA and Quantum Computers * Compiler support for vectorization, thread extraction, task scheduling, speculation, transaction, memory management, data distribution and synchronization Standard research papers must be written in the ACM format<https://www.acm.org/publications/proceedings-template>, and may have up to 11 pages, references excluded. Please ensure that you and your co-authors obtain an ORCID ID, so you can complete the publishing process for your accepted paper. ACM has been involved in ORCID from the start and we have recently made a commitment to collect ORCID IDs from all of our published authors<https://authors.acm.org/author-resources/orcid-faqs>. We are committed to improve author discoverability, ensure proper attribution and contribute to ongoing community efforts around name normalization; your ORCID ID will help in these efforts. By submitting your article to an ACM Publication, you are hereby acknowledging that you and your co-authors are subject to all ACM Publications Policies<https://www.acm.org/publications/policies>, including ACM's new Publications Policy on Research Involving Human Participants and Subjects<https://www.acm.org/publications/policies/research-involving-human-particip…>. Alleged violations of this policy or any ACM Publications Policy will be investigated by ACM and may result in a full retraction of your paper, in addition to other potential penalties, as per ACM Publications Policy. ________________________________ Call for Tool and Practical Experience Papers CGO has a second category of papers called “Tools and Practical Experience”. Papers in this category must either give a clear account of a tool’s functionality or summarize a practical experience with realistic case studies. The successful evaluation of an artifact is mandatory for a Tool Paper. Therefore, authors of work conditionally accepted as Tool Papers must submit an artifact to the Artifact Evaluation Committee. The successful evaluation of the artifact is a requirement for final acceptance. Practical experience papers are encouraged, but not required, to submit an artifact to the Artifact Evaluation process. The selection criteria for papers in this category are: * Originality: Papers should present CGO-related technologies applied to real-world problems with scope or characteristics that set them apart from previous solutions. * Usability: The presented Tools or compilers should have broad usage or applicability. They are expected to assist in CGO-related research, or could be extended to investigate or demonstrate new technologies. If significant components are not yet implemented, the paper will not be considered. * Documentation: The tool or compiler should be presented on a web-site giving documentation and further information about the tool. * Benchmark Repository: A suite of benchmarks for testing should be provided. * Availability: The tool or compiler should be available for public use. * Foundations: Papers should incorporate the principles underpinning Code Generation and Optimization (CGO). However, a thorough discussion of theoretical foundations is not required; a summary of such should suffice. * Artifact Evaluation: The submitted artifact must be functional and support the claims made in the paper. Submission of an artifact is mandatory for papers presenting a tool. Tool and Practical Experience papers abide by the same limit of 11 pages in the ACM format<https://www.acm.org/publications/proceedings-template>, references excluded, and are not distinguished in the final proceedings. We encourage shorter submissions that give account of how scientific ideas have been incorporated and used in practice. ________________________________ Geographic Diversity and Inclusion Authors of papers accepted for CGO 2025 are encouraged to present their work in person. However, to foster the participation of students and professionals from everywhere, CGO 2025 will allow the remote presentation of papers, if their authors are unable to travel to the conference venue for reasons beyond their control (e.g. visa issues). Additionally, the conference organization will try to make attendance of CGO 2025 affordable for as many people as possible, with a specific focus on students from universities located in under-represented countries who are paper authors. ________________________________ Artifact Evaluation The Artifact Evaluation process is run by a separate committee whose task is to assess how the artifacts support the work described in the papers. This process contributes to improved reproducibility in research that should be a great concern to all of us. There is also some evidence that papers with a supporting artifact receive higher citations than papers without artifact evaluation. Authors of accepted papers at CGO have the option of submitting their artifacts for evaluation within two weeks of paper acceptance. To ease the organization of the AE committee, we kindly ask authors to indicate at the time they submit the paper, whether they are interested in submitting an artifact. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Additional information is available on the CGO AE web page. Authors of accepted papers are encouraged, but not required, to make these materials publicly available upon publication of the proceedings. ________________________________ Authors should carefully consider the difference in focus between the co-located conferences when deciding where to submit a paper. CGO will make the proceedings freely available via the IEEE Xplore platform during the period from two weeks before to two weeks after the conference. This option will facilitate easy access to the proceedings by conference attendees, and it will also enable the community at large to experience the excitement of learning about the latest developments being presented in the period surrounding the event itself. ________________________________ Distinguished Paper Awards Up to 10% of papers accepted at CGO 2025 will be designated as Distinguished Papers, following the ACM policy. This award is open to both regular and tool papers.

1 0