- Haskell-Cafe - Haskell.org

How to use locally compiled GHC?
by Stefan Klinger 02 Dec '25

02 Dec '25

Hello, what do I have to do to use a locally compiled GHC on my own projects? Background: I'm working on this [1]. I've managed to compile GHC following the instructions given on https://ghc.dev, also here [2]. I can run $ ./_build/stage1/bin/ghc --interactive GHCi, version 9.15.20251202: https://www.haskell.org/ghc/ :? for help with the expected result. However, the locally built compiler (master branch, without any modifications) fails with all but the most primitive of my own projects. I try to do this by adding a line with-compiler: /home/sk/prg/ghc/master/_build/stage1/bin/ghc to the `cabal.project` file of a project. Then, success depends on the dependencies of a project. Here is one using `criterion`: $ cabal build Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.12.1.0 supports 'ghc' version < 9.12): /home/sk/prg/ghc/third/_build/stage1/bin/ghc is version 9.15.20251202 Resolving dependencies... Error: [Cabal-7107] Could not resolve dependencies: [__0] next goal: foo (user goal) [__0] rejecting: foo-1.0 (constraint from user target requires ==0.0.1) [__0] trying: foo-0.0.1 [__1] trying: criterion-1.6.4.1 (dependency of foo) [__2] trying: vector-algorithms-0.9.1.0 (dependency of criterion) [__3] trying: primitive-0.9.1.0 (dependency of vector-algorithms) [__4] next goal: base (dependency of foo) [__4] rejecting: base-4.22.0.0/installed-inplace (conflict: primitive => base>=4.10 && <4.22) [__4] rejecting: base; 4.21.0.0, 4.20.2.0, 4.20.1.0, 4.20.0.1, 4.20.0.0, 4.19.2.0, 4.19.1.0, 4.19.0.0, 4.18.3.0, 4.18.2.1, 4.18.2.0, 4.18.1.0, 4.18.0.0, 4.17.2.1, 4.17.2.0, 4.17.1.0, 4.17.0.0, 4.16.4.0, 4.16.3.0, 4.16.2.0, 4.16.1.0, 4.16.0.0, 4.15.1.0, 4.15.0.0, 4.14.3.0, 4.14.2.0, 4.14.1.0, 4.14.0.0, 4.13.0.0, 4.12.0.0, 4.11.1.0, 4.11.0.0, 4.10.1.0, 4.10.0.0, 4.9.1.0, 4.9.0.0, 4.8.2.0, 4.8.1.0, 4.8.0.0, 4.7.0.2, 4.7.0.1, 4.7.0.0, 4.6.0.1, 4.6.0.0, 4.5.1.0, 4.5.0.0, 4.4.1.0, 4.4.0.0, 4.3.1.0, 4.3.0.0, 4.2.0.2, 4.2.0.1, 4.2.0.0, 4.1.0.0, 4.0.0.0, 3.0.3.2, 3.0.3.1 (constraint from non-reinstallable package requires installed instance) [__4] fail (backjumping, conflict set: base, foo, primitive) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: base, primitive, vector-algorithms, criterion, uvector, foo Try running with --minimize-conflict-set to improve the error message. And similar problems occur when depending on `unliftio` or `attoparsec`. How should I approach this? And I expect to run into similar questions in the near future, i.e., related to bulding, testing, using, but not necessarily related to [1]. Where should I ask? Kind regards Stefan [1]: https://github.com/haskell/core-libraries-committee/issues/367 [2]: https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing -- Stefan Klinger, Ph.D. -- computer scientist o/X http://stefan-klinger.de /\/ https://github.com/s5k6 \ I prefer receiving plain text messages, not exceeding 32kB.

2 2

GHC 9.14.1-rc3 is now available
by Zubin Duggal 02 Dec '25

02 Dec '25

The previous email had an incorrect subject line, GHC 9.14.1-rc3 is what it was intended to say. The contents following this are the same. The GHC developers are very pleased to announce the availability of the third release candidate of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. The changes from the second release candidate are: - Fix RTS segfaults in certain situations (#26495) - Fix use after free on windows due to a linker optimisation introduced in an earlier RC (#26613) GHC 9.14 will bring a number of new features and improvements, including: * Significant improvements in specialisation: * The `SPECIALISE` pragma now allows use of type application syntax * The `SPECIALISE` pragma can be used to specialise for expression arguments as well as type arguments. * Specialisation is now considerably more reliable in the presence of `newtype`s * Significant GHCi improvements including: * Correctness and performance improvements in the bytecode interpreter * Features in the GHCi debugger * Support for multiple home units in GHCi * Implementation of the [Explicit Level Imports proposal][levels] * `RequiredTypeArguments` can now be used in more contexts * SSE/AVX2 support in the x86 native code generator backend * A major update of the Windows toolchain and improved compatibility with macOS Tahoe * ... and many more A full accounting of changes can be found in the [release notes][]. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads. Note that while this release makes many improvements in the specialisation optimisation, polymorphic specialisation will remain disabled by default in the final release due to concern over regressions of the sort identified in [#26329][T26329]. Users needing more aggressive specialisation can explicitly enable this feature with the `-fpolymorphic-specialisation` flag. Depending upon our experience with 9.14.1, we may enable this feature by default in a later minor release. GHC development is sponsored by: * [Juspay](https://juspay.com/) * [QBayLogic](https://qbaylogic.com/) * [Channable](https://www.channable.com/) * [Haskell Foundation](https://haskell.foundation/) * [Serokell](https://serokell.io/) * [Well-Typed](https://well-typed.com/) * [Tweag](https://www.tweag.io/) * [Dotcom-Monitor](https://www.dotcom-monitor.com/) * [LoadView](https://www.loadview-testing.com/) * [Web Hosting Buddy](https://webhostingbuddy.com/) * [Find My Electric](https://www.findmyelectric.com/) * [Standard Chartered](https://www.sc.com) * [UpCloud](https://upcloud.com) We would like to that these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. [downloads.haskell.org] https://downloads.haskell.org/ghc/9.14.1-rc3 [release notes]: https://downloads.haskell.org/ghc/9.14.1-rc3/docs/users_guide/9.14.1-notes.… [ticket]: https://gitlab.haskell.org/ghc/homepage/-/issues/new [macos]: https://gitlab.haskell.org/ghc/ghc/-/issues/26166 [T26329]: https://gitlab.haskell.org/ghc/ghc/-/issues/26329 [levels]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0682-e…

1 0

GHC 9.12.3-rc3 is now available
by Zubin Duggal 02 Dec '25

02 Dec '25

The GHC developers are very pleased to announce the availability of the third release candidate of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. The changes from the second release candidate are: - Fix RTS segfaults in certain situations (#26495) - Fix use after free on windows due to a linker optimisation introduced in an earlier RC (#26613) GHC 9.14 will bring a number of new features and improvements, including: * Significant improvements in specialisation: * The `SPECIALISE` pragma now allows use of type application syntax * The `SPECIALISE` pragma can be used to specialise for expression arguments as well as type arguments. * Specialisation is now considerably more reliable in the presence of `newtype`s * Significant GHCi improvements including: * Correctness and performance improvements in the bytecode interpreter * Features in the GHCi debugger * Support for multiple home units in GHCi * Implementation of the [Explicit Level Imports proposal][levels] * `RequiredTypeArguments` can now be used in more contexts * SSE/AVX2 support in the x86 native code generator backend * A major update of the Windows toolchain and improved compatibility with macOS Tahoe * ... and many more A full accounting of changes can be found in the [release notes][]. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads. Note that while this release makes many improvements in the specialisation optimisation, polymorphic specialisation will remain disabled by default in the final release due to concern over regressions of the sort identified in [#26329][T26329]. Users needing more aggressive specialisation can explicitly enable this feature with the `-fpolymorphic-specialisation` flag. Depending upon our experience with 9.14.1, we may enable this feature by default in a later minor release. GHC development is sponsored by: * [Juspay](https://juspay.com/) * [QBayLogic](https://qbaylogic.com/) * [Channable](https://www.channable.com/) * [Haskell Foundation](https://haskell.foundation/) * [Serokell](https://serokell.io/) * [Well-Typed](https://well-typed.com/) * [Tweag](https://www.tweag.io/) * [Dotcom-Monitor](https://www.dotcom-monitor.com/) * [LoadView](https://www.loadview-testing.com/) * [Web Hosting Buddy](https://webhostingbuddy.com/) * [Find My Electric](https://www.findmyelectric.com/) * [Standard Chartered](https://www.sc.com) * [UpCloud](https://upcloud.com) We would like to that these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. [downloads.haskell.org] https://downloads.haskell.org/ghc/9.14.1-rc3 [release notes]: https://downloads.haskell.org/ghc/9.14.1-rc3/docs/users_guide/9.14.1-notes.… [ticket]: https://gitlab.haskell.org/ghc/homepage/-/issues/new [macos]: https://gitlab.haskell.org/ghc/ghc/-/issues/26166 [T26329]: https://gitlab.haskell.org/ghc/ghc/-/issues/26329 [levels]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0682-e…

1 0

Midlands Graduate School, Nottingham, UK, 13-17 April 2026
by Graham Hutton (staff) 01 Dec '25

01 Dec '25

Dear all, I'm delighted to announce that the next Midlands Graduate School (MGS) in the Foundations of Computing Science will be held in Nottingham, UK, from 13-17 April 2026. Please share in your communities! Best wishes, Graham Hutton ========================================================== MIDLANDS GRADUATE SCHOOL 2026 13-17 April 2026, Nottingham, UK https://tinyurl.com/MGS-2026 ========================================================== BACKGROUND The Midlands Graduate School (MGS) in the Foundations of Computing Science provides a yearly programme of courses on the mathematical foundations of computing, and recently celebrated its 25th year. The MGS is primarily aimed at PhD students in their first or second year, but is open to everyone, and has increasingly seen participation from industry. We welcome participants from all over the world! COURSES Eight courses will be given. Participants usually take around four courses, depending on their interests. Invited course: - To be announced Introductory courses: - Category Theory for the Lazy Functional Programmer Thorsten Altenkirch (Nottingham) - Introduction to HoTT/UF with Agda Martin Escardó (Birmingham) - Lambda Calculus and Combinatory Algebra Sam Speight (Birmingham) Advanced courses: - Effects and Call-By-Push-Value Paul Blain Levy (Birmingham) - Synthetic Homotopy Theory Axel Ljungström (Nottingham) - Categorical Algebra and Logic Sean Moss (Birmingham) - Inductive and Coinductive Reasoning with Isabelle/HOL Andrei Popescu (Sheffield) LOCAL ORGANISERS For any queries, please contact the local organisers: Ulrik Buchholtz <ulrik.buchholtz(a)nottingham.ac.uk> Dan Marsden <dan.marsden(a)nottingham.ac.uk> ========================================================== This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

Jonathan Bowen to give the Peter Landin Semantics Seminar: 4 December 2025, BCS London office and on Zoom
by Andrei Popescu 26 Nov '25

26 Nov '25

Dear Colleagues, Please see below details about the event, which will be preceded by the BCS-FACS Annual General Meeting. The event can be attended either online or in person. Best wishes, Andrei https://www.bcs.org/events-calendar/2025/december/hybrid-facs-agm-and-peter… (free registration online) Hybrid event: *BCS-FACS AGM & Peter Landin Semantics Seminar* *Formal Methods: Whence and Whither* BCS London office (near Moorgate underground station) and on Zoom, 4 December 2025 Speaker: *J <https://sites.google.com/site/jpbowen/>**onathan Bowen <https://sites.google.com/site/jpbowen/>* (Chair of FACS)Agenda 3:30pm - Networking for attendees (refreshments and biscuits) *4:00pm* - 5:00pm *FACS AGM* (optional!) 5:15pm - Networking for physical/online attendees. Includes refreshments and biscuits for those in person. *6:00pm* - *Peter **Landin Semantics Seminar Talk* 7:00pm - Questions and answers 7:15pm - Networking for physical attendees (light refreshments) 8:00pm - Event ends for online attendees *8:30pm* - Event ends for in-person attendees Synopsis Alan Turing arguably wrote the first paper on formal methods over 75 years ago. Since then, there have been claims and counterclaims about formal methods. Tool development has been slow but aided by Moore’s Law, with the increasing power of computers. Although formal methods are not widespread in practical usage at a heavyweight level, their influence has crept into software engineering practice to the extent that they are no longer necessarily called formal methods in their use. In addition, in areas where safety and security are important, with the increasing use of computers in such applications, formal methods are a viable way to improve the reliability of such software-based systems. Their use in hardware, where a mistake can be very costly, is also important. This talk explores the journey of formal methods to the present day and speculates on future directions, including the use of Artificial Intelligence. About the speaker *Jonathan Bowen*, FBCS FRSA, is Chairman of Museophile Limited (founded in 2002), an Emeritus Professor at London South Bank University, where he was Professor of Computing, establishing and heading the Centre for Applied Formal Methods from 2000. From 2017, he has been an Adjunct Professor at Southwest University, Chongqing, China. Between 2013–15, he was Professor of Computer Science at Birmingham City University. During 2006–07, he was a visiting academic at University College London. Between 2007–09, he was a Visiting Professor at King's College, London, and during 2008–09, he was an Associate at Praxis High Integrity Systems (now Altran). From 2010, he was a Visiting Professor at the University of Westminster. During 2010, he was a Visiting Professor at Waikato University in New Zealand, and in 2012, he was a Visiting Professor at the Pratt Institute in New York. He is the current Chair of the BCS-FACS Specialist Group. ------------------------ Our events are for adults aged 16 years and over. BCS is a membership organisation. If you enjoy this event, please consider joining BCS. You’ll be very welcome. You’ll receive access to many exclusive career development tools, an introduction to a thriving professional community and also help us Make IT Good For Society. Join BCS today <https://www.bcs.org/membership/events> Please note: if you have any accessibility needs, please let us know via groups(a)bcs.uk and we’ll work with you to make suitable arrangements. If you are attending in person, please familiarise yourself with the Visitor Instructions <https://www.bcs.org/media/ww4jlkud/visitor-instructions.docx> for the BCS London Office. For overseas delegates who wish to attend the event, please note that BCS does not issue invitation letters. Photo by Markus Spiske This event is brought to you by: FACS (Formal Aspects of Computing Science) group <https://www.bcs.org/membership-and-registrations/member-communities/facs-fo…>

1 0

CfP: SLE 2026 - 19th ACM SIGPLAN International Conference on Software Language Engineering
by Andrei Chis 20 Nov '25

20 Nov '25

19th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2026) 2 - 3 July 2026 Rennes, France https://conf.researchr.org/home/sle-2026 https://www.sleconf.org/2026/ ------------------------------------------------------------------------ We are pleased to invite you to submit papers to the 19th ACM SIGPLAN International Conference on Software Language Engineering (SLE) which is devoted to the principles of software languages: their design, their implementation, and their evolution. The SLE 2026 conference will be co-located with STAF 2026 and hosted in Rennes, France, on 2 - 3 July 2026. --------------------------- Important Dates --------------------------- * Abstract submission (all tracks): Friday 27 February 2026 * Paper submission (all tracks): Friday 6 March 2026 * Paper notification (all tracks): Monday 20 April 2026 * Conference: Thursday 2 - Friday 3 July 2026 (co-located with STAF) All dates are Anywhere on Earth. --------------------------- Topics of Interest --------------------------- SLE covers software language engineering in general, rather than engineering a specific software language. Topics of interest include, but are not limited to: *Software Language Design and Implementation - Approaches to and methods for language design - Static semantics (e.g., design rules, well-formedness constraints) - Techniques for specifying behavioral/executable semantics - Generative approaches (incl. code synthesis, compilation) - Meta-languages, meta-tools, language workbenches - AI-assisted language design and optimisation * Software Language Quality - Verification and formal methods for languages - Testing techniques for languages - Simulation techniques for languages - Model-based testing - AI-assisted validation * Software Language Integration and Composition - Coordination of heterogeneous languages and tools - Mappings between languages (incl. transformation languages) - Traceability between languages - Deployment of languages to different platforms - (AI-assisted) Language refactorings * Software Language Maintenance - Software language reuse - Language evolution - Language families and variability, language and software product lines * Domain-specific approaches for any aspects of SLE (design, implementation, validation, maintenance) * Empirical evaluation and experience reports of language engineering tools - User studies evaluating usability - Performance benchmarks - Industrial applications * Synergies between Language Engineering and emerging/promising research areas - Generative AI in language engineering (e.g., AI-based language modelling, AI-driven code generation tools) - Language engineering for AI. AI and ML language engineering (e.g., ML compiler testing, code classification, DSLs for AI processes and tasks…) - Quantum language engineering (e.g., language design for quantum machines) - Language engineering for physical systems (e.g., CPS, IoT, digital twins) - Socio-technical systems and language engineering (e.g., language evolution to adapt to social requirements) --------------------------- Types of Submissions --------------------------- SLE accepts the following types of papers: * Research papers: These are “traditional” papers detailing research contributions to SLE. Papers may range from 6 to 12 pages in length and may optionally include 2 further pages of bibliography/appendices. Papers will be reviewed with an understanding that some results do not need 12 full pages and may be fully described in fewer pages. * New ideas/vision papers: These papers may describe new, unconventional software language engineering research positions or approaches that depart from standard practice. They can describe well-defined research ideas that are at an early stage of investigation. They could also provide new evidence to challenge common wisdom, present new unifying theories about existing SLE research that provides novel insight or that can lead to the development of new technologies or approaches, or apply SLE technology to radically new application areas. New ideas/vision papers must not exceed 5 pages and may optionally include 1 further page of bibliography/appendices. * SLE Body of Knowledge: The SLE Body of Knowledge (SLEBoK) is a community-wide effort to provide a unique and comprehensive description of the concepts, best practices, tools, and methods developed by the SLE community. In this respect, the SLE conference will accept surveys, essays, open challenges, empirical observations, and case study papers on the SLE topics. These can focus on, but are not limited to, methods, techniques, best practices, and teaching approaches. Papers in this category can have up to 20 pages, including bibliography/appendices. * Tool papers: These papers focus on the tooling aspects often forgotten or neglected in research papers. A good tool paper focuses on practical insights that will likely be useful to other implementers or users in the future. Any of the SLE topics of interest are appropriate areas for tool papers. Submissions must not exceed 5 pages and may optionally include 1 further page of bibliography/appendices. They may optionally include an appendix with a demo outline/screenshots and/or a short video/screencast illustrating the tool. **Workshops**: Workshops will be organised by STAF. Please inform us and contact STAF 2026 organisers if you would like to organise a workshop of interest to the SLE audience. Information on how to submit workshops can be found on the STAF 2026 Website. --------------------------- Submission --------------------------- SLE 2026 has a single submission round for papers, including a mandatory abstract registration. Authors of accepted research papers will be invited to submit artefacts. --------------------------- Format --------------------------- Submissions have to use the ACM SIGPLAN Conference Format “acmart” ( https://sigplan.org/Resources/Author/#acmart-format) please make sure that you always use the latest ACM SIGPLAN acmart LaTeX template, and that the document class definition is \documentclass[sigplan,anonymous,review]{acmart}. Do not make any changes to this format! Ensure that your submission is legible when printed on a black and white printer. In particular, please check that colours remain distinct and font sizes in figures and tables are legible. To increase fairness in reviewing, a double-blind review process has become standard across SIGPLAN conferences. Accordingly, SLE will follow the double-blind process. Author names and institutions must be omitted from submitted papers, and references to the authors’ own related work should be in the third person. No other changes are necessary, and authors will not be penalized if reviewers are able to infer their identities in implicit ways. All submissions must be in PDF format. You can access the submission site from the conference website: https://conf.researchr.org/home/sle-2026 --------------------------- Concurrent Submissions --------------------------- Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy ( https://www.sigplan.org/Resources/Policies/Republication/) Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism ( https://www.acm.org/publications/policies/plagiarism-overview) Submissions that violate these policies will be desk-rejected. --------------------------- Policy on Human Participant and Subject Research --------------------------- Authors conducting research involving human participants and subjects must ensure that their research complies with their local governing laws and regulations and the ACM’s general principles, as stated in the ACM’s Publications Policy on Research Involving Human Participants and Subjects ( https://www.acm.org/publications/policies/research-involving-human-particip…) If submissions are found to be violating this policy, they will be rejected. --------------------------- Reviewing Process --------------------------- All submitted papers will be reviewed by at least three members of the program committee. Research papers and tool papers will be evaluated concerning soundness, relevance, novelty, presentation, validation, and replicability. New ideas/vision papers will be evaluated primarily concerning soundness, relevance, novelty, and presentation. Tool papers will be evaluated concerning relevance, presentation, and replicability. For fairness reasons, all submitted papers must conform to the above instructions. Submissions that violate these instructions may be rejected without review at the discretion of the PC chairs. --------------------------- Artefact Evaluation --------------------------- SLE will use an evaluation process to assess the quality of artefacts on which papers are based to foster the culture of experimental reproducibility. Authors of accepted research papers are invited to submit artefacts. --------------------------- Awards --------------------------- * Distinguished paper: Award for the most notable paper, as determined by the PC chairs based on the recommendations of the program committee. * Distinguished artefact: Award for the artefact most significantly exceeding expectations, as determined by the AEC chairs based on the recommendations of the artefact evaluation committee. * Distinguished reviewer: Award for the programme committee member that produced the most useful reviews as assessed by paper authors. * Most Influential Paper: Award for the SLE 2016 paper with the greatest impact, as judged by the SLE Steering Committee. --------------------------- Publication --------------------------- All accepted papers will be published in the ACM Digital Library. **AUTHORS TAKE NOTE**: The official publication date 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. --------------------------- Organisation --------------------------- * General chair: Arnaud Blouin, Univ Rennes, INSA Rennes, Inria, CNRS, IRISA * PC co-chair: Jordi Cabot, Luxembourg Institute of Science and Technology * PC co-chair: Shigeru Chiba, University of Tokyo, Japan --------------------------- Contact --------------------------- For additional information, clarification, or answers to any questions, please get in touch with the program co-chairs (jordi.cabot(a)list.lu and chiba(a)g.ecc.u-tokyo.ac.jp)

1 0

Haskell.org Committee: Call for Nominations
by Rebecca Skinner 20 Nov '25

20 Nov '25

Dear Haskellers, We are pleased to announce that nominations are now open for the Haskell.org committee. You can nominate yourself or a friend for a three-year term (2026-2028) by sending an email to [committee at haskell.org] by December 05, 2025. There are three seats open for election this year. The committee will elect members in December 2025 for the term beginning in January 2026. Self-nominations and re-nominations are also welcome. Please include any relevant information about yourself or your nominee that you think will help us make our decision. Committee members do not have to be technical experts in Haskell. We are looking for people who are enthusiastic about improving the Haskell community and come from a variety of backgrounds, such as academia, industry, open-source development, and community building. Our goal is to represent the various facets of the Haskell world, including gender, race, location, and industry or research. The committee’s responsibilities include setting policies, providing guidance for Haskell.org infrastructure, planning for the long term, and being fiscally responsible with Haskell.org funds and donations. Being a committee member does not require a significant amount of time, but members should be responsive during discussions and should be able to attend monthly calls and participate in the Haskell.org Slack and mailing lists. Candidates for the committee should possess strong leadership, communication, and judgment skills. They must be able to set aside personal or business-related biases and make decisions with the good of the open-source Haskell community in mind. For more information about the committee’s roles and responsibilities, please visit Haskell.org Committee If you have any questions about the nomination process, please feel free to email us at [committee at haskell.org] or contact one of us individually.

1 0

Final Call for Papers: Tests and Proofs (TAP) -- Now a Track at FM 2026
by Achim D. Brucker 18 Nov '25

18 Nov '25

**CALL FOR PAPERS** **Special Track on Tests and Proofs (TAP 2026)** *at the* **27th International Symposium on Formal Methods (FM 2026)** **May 18-22, 2026 --- Tokyo, Japan** **Website:** <https://conf.researchr.org/track/fm-2026/> **Abstract Submission**: Tuesday, 25 November 2025 **Full Paper Submission:** Tuesday, 2 December 2025 ### **New TAP Track at FM 2026: A Premier Venue for Tests and Proofs** Since 2007, the [Test and Proof (TAP) conference](https://tapconference.github.io/2024/) has long been a leading venue for research on the intersection of software testing and formal verification. Now, TAP is joining the 27th International Symposium on Formal Methods (FM 2026) as a new special track. This integration places the ground-breaking work of the Test and Proofs community at the heart of the world's premier conference on formal methods. This new track provides a dedicated forum for researchers, practitioners, and tool developers to present and discuss the latest advances in the synergistic combination of traditionally distinct areas of dynamic analysis, e.g., testing, and static analysis, e.g., proving. By joining FM, the TAP track offers authors a wider, more diverse audience and the prestige of publication in the main, open-access FM 2026 proceedings, published by Springer in the LNCS series. We invite you to be part of this exciting new chapter for the tests and proofs community! **Track Highlight: FM 2026 Keynote by Professor Cristian Cadar** We are thrilled to announce that TAP Track at FM 2026 will feature a keynote address by **Professor Cristian Cadar** of Imperial College London. Professor Cadar is a world-renowned authority on software reliability, security, and verification, and is particularly celebrated for his pioneering contributions to symbolic and dynamic execution (e.g., KLEE). His selection as a main symposium keynote speaker is a powerful testament to the increasing importance of the core topics of the TAP track to the broader computer science community. ### **Scope and Topics of Interest** The TAP track solicits high-quality, original research on the interplay between dynamic techniques such as testing, runtime verification etc.testing and formal verification such as proving, model checking, abstract interpretation, etc. . The track aims to foster new collaborations and advance the state of the art in creating reliable and secure software and systems. Topics of interest include, but are not limited to, the following areas: **Foundations for Combining Testing and Verification** - Formalisms and theories that unify testing and proof\ - Semantic foundations for combined static and dynamic analysis\ - Proof theory for test-case generation and specification conformance\ - Type systems with a testing and proving focus\ - Formal models of test-based and proof-based development **Synergistic Techniques and Tools** - Combination of model checking, theorem proving, and runtime verification - Synergies between symbolic execution, fuzzing, and formal analysis - Test-case generation from formal specifications (e.g., using B, Z, TLA+, VDM) - Using test execution results to guide or automate proof discovery - Static analysis for test-suite reduction, prioritization, and optimization - Verification-based and property-based testing - Formal methods for testing AI/ML-based systems - AI/ML techniques for enhancing formal verification and testing - Derivation of specifications and contracts from tests - Combination of static and dynamic analysis for security vulnerability detection **Applications and Empirical Evaluation** - Case studies and experience reports applying combined test-and-proof techniques to industrial systems (e.g., in security, cyber-physical systems, autonomous systems, blockchain, or IoT) - Empirical comparisons of different verification, testing, and combined techniques - Tool demonstration papers for new and innovative tools that support tests and proofs - Application of TAP techniques to challenge problems and benchmarks ### **Submission Categories and Guidelines** The TAP track papers can be submitted in all paper categories supported by the FM 2026 Research Track and submissions to the TAP track will be reviewed following the policies and quality criteria of the FM Research Track. The TAP track solicits papers in the following categories: - **Regular Papers (max 15 pages, excluding references and appendices):** For mature, original research contributions. - **Long Tool Papers (max 15 pages, excluding references and appendices):** For presenting mature tools, their theoretical foundations, and empirical evaluations. - **Case Study Papers (max 15 pages, excluding references and appendices):** For in-depth reports on the application of TAP techniques to significant, real-world problems. - **Short Papers (max 6 pages, excluding references and appendices):** For presenting novel but not yet fully mature ideas, or for tool demonstration papers that focus on a tool's features and usage. Papers should be original work, not published or submitted elsewhere, in Springer [LNCS format](https://www.springer.com/gp/computer-science/lncs/conference-procee…, and written in English. Submit your papers at https://easychair.org/conferences/?conf=fm2026 Reviewing is single-blind. Each paper will be evaluated by at least three members of the Program Committee. Papers will be accepted or rejected in the category in which they were submitted and will not be moved between categories Authors of accepted papers are strongly encouraged to submit their supporting artifacts to the FM 2026 Artifact Evaluation track. ### **Important Dates** All deadlines are **Anywhere on Earth (AoE, UTC-12h)**. The deadlines for the TAP track are aligned with the FM 2026 Research Track. Milestone Date --------------------------- ------------------------------- **Abstract Submission** **Tuesday, 25 November 2025** **Full Paper Submission** **Tuesday, 2 December 2025** **Author Notification** **Friday, 6 February 2026** **Camera-Ready Version** **Monday, 2 March 2026** **FM 2026 Conference** **May 18-22, 2026** ### **Publication** All accepted papers for the TAP track will be published as part of the main FM 2026 conference proceedings. The proceedings will be published by Springer in their **open-access Lecture Notes in Computer Science (LNCS)** series. At least one author of an accepted paper must register for the conference and present the work. ### **Track Organization** **Track Chairs:** - Marie-Christine Jakobs, Ludwig-Maximilan University, Munich, Germany - Achim D. Brucker, University of Exeter, UK For inquiries, please contact the track chairs. -- Prof. Achim Brucker | Chair in Cybersecurity & Head of Group | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

Re: lost polymorphism in Typed Tagless Final Interpreters
by Olaf Klinke 12 Nov '25

12 Nov '25

> So change lit <$> safeRead n to (\x -> > lit x) <$> safeRead n, for example. Does anyone else find this highly non-obvious? SPJ gives an example https://github.com/ghc-proposals/ghc-proposals/pull/287#issuecomment-543683… of a context that can indeed distinguish, semantically, a function and its eta expansion. But the fact that, for the benefit of soundness, there must exist contexts where one can be a well-typed program while the other is not, is still mysterious to me. Can a type system with polymorphism really not do better than this? The discussion thread has some more interesting posts, e.g. https://github.com/ghc-proposals/ghc-proposals/pull/287#issuecomment-544377… https://github.com/ghc-proposals/ghc-proposals/pull/287#issuecomment-112046… At least, thanks to Jaro, the error index now explains when you should eta-expand. https://errors.haskell.org/messages/GHC-83865/ Olaf

2 1

lost polymorphism in Typed Tagless Final Interpreters
by Anthony Carrico 12 Nov '25

12 Nov '25

In his tutorial lecture "Typed Tagless Final Interpreters" https://www.okmij.org/ftp/tagless-final/course/lecture.pdf Oleg Kiselyov deals with the issue of losing polymorphism, tf1'_both :: IO() tf1'_both = case tf1' of Left e -> putStrLn ("Error: " ++ e) Right (x) -> do print (eval x) print (view x) "We have lost polymorphism. The problem is subtle: the function fromTree is indeed polymorphic over repr, as its inferred type shows. However, to extract the de-serialized term, we have to do pattern-matching; the variable x is bound in the case pattern and hence, like a lambda-pattern–bound variable, gets a monomorphic, non-generalizable type. Therefore, we cannot interpret x with several arbitrary interpreters; the extensibility is lost." He shows how to use a newtype wrapper to work around the issue, but also says in a foot note: "With the impredicative polymorphism GHC extension, we do not have to fake first-class polymorphism and do not need Wrapped." Two questions: 1. Is this true? I still get the error. 2. Can anyone summarize the current state of this issue today? It can be hard follow the issue through the history of Haskell/GHC. Thanks to Oleg for publishing this lecture, it is possible to learn quite a bit from it, and thanks to whoever would like to give an update! I've smashed together my source code from the F module and the Serialization module together below. You can see the "defered type error" at the very bottom. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 9.8.4 {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ImpredicativeTypes #-} module F where class ExpSYM repr where lit :: Int -> repr neg :: repr -> repr add :: repr -> repr -> repr instance ExpSYM Int where lit n = n neg e = -e add e0 e1 = e0 + e1 eval :: Int -> Int eval = id instance ExpSYM String where lit n = show n neg e = "(-" ++ e ++ ")" add e0 e1 = "(" ++ e0 ++ " + " ++ e1 ++ ")" view :: String -> String view = id data Tree = Leaf String | Node String [Tree] deriving (Eq, Read, Show) instance ExpSYM Tree where lit n = Node "Lit" [Leaf (show n)] neg e = Node "Neg" [e] add e0 e1 = Node "Add" [e0, e1] toTree :: Tree -> Tree toTree = id type ErrMsg = String safeRead :: Read a => String -> Either ErrMsg a safeRead s = case reads s of [(x, "")] -> Right x _ -> Left $ "Read error: " ++ s fromTree :: (ExpSYM repr) => Tree -> Either ErrMsg repr fromTree (Node "Lit" [Leaf n]) = lit <$> (safeRead n) fromTree (Node "Neg" [e]) = neg <$> (fromTree e) fromTree (Node "Add" [e0, e1]) = add <$> (fromTree e0) <*> (fromTree e1) fromTree e = Left ("Invalid tree: " ++ show e) tf1 :: ExpSYM repr => repr tf1 = add (lit 8) (neg (add (lit 1) (lit 2))) tf1_tree :: Tree tf1_tree = toTree F.tf1 tf1' :: ExpSYM repr => Either ErrMsg repr tf1' = fromTree tf1_tree tf1'_eval :: IO() tf1'_eval = case tf1' of Left e -> putStrLn ("Error: " ++ e) Right x -> print (eval x) -- >>> tf1'_eval -- 5 tf1'_view :: IO() tf1'_view = case tf1' of Left e -> putStrLn ("Error: " ++ e) Right x -> print (view x) -- >>> tf1'_view -- "(8 + (-(1 + 2)))" tf1'_both :: IO() tf1'_both = case tf1' of Left e -> putStrLn ("Error: " ++ e) Right (x) -> do print (eval x) print (view x) -- >>> tf1'_both -- *** Exception: /tmp/danteIpH3fg.hs:90:19: error: [GHC-83865] -- • Couldn't match type ‘Int’ with ‘[Char]’ -- Expected: String -- Actual: Int -- • In the first argument of ‘view’, namely ‘x’ -- In the first argument of ‘print’, namely ‘(view x)’ -- In a stmt of a 'do' block: print (view x) -- (deferred type error) -- Anthony Carrico

2 2