The GHC developers are very pleased to announce the availability
of the final release for GHC 9.10.3. Binary distributions, source
distributions, and documentation are available at [downloads.haskell.org][].
GHC 9.10.3 is a bug-fix release fixing many issues of a variety of
severities and scopes, including:
* Fix a number of crashes in the compiler frontend (#25960, #25004, #25056)
* Fix incorrect results in the NCG (#25601, #26061)
* Support for far jumps in the AArch64 NCG (#24648)
* A fix for a segfault in the RTS when running certain code involving STM (#26205)
* And many more!
A full accounting of these fixes can be found in the [release notes][]. As
always, GHC's release status, including planned future releases, can be found on
the GHC Wiki [status][].
We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable,
Serokell, SimSpace, the Haskell Foundation, 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.
[release notes]: https://downloads.haskell.org/~ghc/9.10.3/docs/users_guide/9.10.3-notes.html
[status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status
[downloads.haskell.org] https://downloads.haskell.org/ghc/9.10.3
[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
Dear all,
This is a reminder that only one week is left to submit tutorial proposals<https://2026.cgo.org/track/cgo-2026-workshops-and-tutorials> for CGO 2026 (deadline 17th September).
The International Symposium on Code Generation and Optimization (CGO) provides a 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 will be held in Sydney, Australia from 31st January – 4th February 2026 and tutorials (half- or full-day) will be held before the main conference.
Best,
Luisa
Hi everyone!!
We are really excited to announce Copilot 4.5.1 [1,2]. Copilot is a
stream-based EDSL in Haskell for writing and monitoring embedded C
programs, with an emphasis on correctness and hard realtime
requirements. Copilot is typically used as a high-level runtime
verification framework, and supports temporal logic (LTL, PTLTL and
MTL), clocks and voting algorithms. Compilation to Bluespec, to target
FPGAs, is also supported.
Copilot is NASA Class D open-source software, and is being used at NASA
in drone test flights. Through the NASA tool Ogma [3] (also written in
Haskell), Copilot also serves as a programming language and runtime
framework for NASA's Core Flight System, Robot Operating System (ROS2),
FPrime (the software framework used in the Mars Helicopter). Ogma now
supports producing flight and robotics applications directly in
Copilot, not just for monitoring, but for implementing the logic of the
applications themselves.
Since the last announcement, the major updates and improvements are:
- Copilot maintream now includes the verification, FPGA and
visualization backends.
- Copilot now includes a tutorial showing how to generate code for FPGA
and run it (thanks to Sukhman Kahlon!).
- Compatibility with newer versions of dependencies has been extended.
- Cleaning efforts in `copilot-theorem`, and `copilot-core`.
A picture of the Copilot visualizer can be seen at [5].
The new implementation is compatible with versions of GHC from 8.6 to
9.12.
This release has been made possible thanks to key submissions from
Sukhman Kahlon (NASA). We also thank Corey Carter (NASA), Ryan Scott
(Galois) and Kaveh Zare (NASA) for their input. We are grateful to them
for their contributions, and for making Copilot better every day.
For details on this release, see [1].
As always, we're releasing exactly 2 months since the last release. Our
next release is scheduled for Nov 7th, 2025.
We want to remind the community that Copilot is now accepting code
contributions from external participants again. Please see the
discussions and the issues in our github repo [4] to learn how to
participate.
Current emphasis is on using Copilot for full data processing
applications (e.g, system control, arduinos, rovers, drones), improving
usability, performance, and stability, increasing test coverage,
removing unnecessary dependencies, hiding internal definitions, and
formatting the code to meet our coding standards. Users are encouraged
to participate by opening issues, asking questions, extending the
implementation, and sending bug fixes.
Happy Haskelling!
Ivan
--
[1] https://github.com/Copilot-Language/copilot/releases/tag/v4.5.1
[2] https://hackage.haskell.org/package/copilot
[3] https://github.com/nasa/ogma
[4] https://github.com/Copilot-Language/copilot
[5] https://www.reddit.com/r/haskell/comments/1nci0u6/ann_copilot_451/
==========================================================
Call for Participation
IFL 2025
37th Symposium on Implementation and Application of Functional Languages
Montevideo, Uruguay
October 1-3, 2025
(Tutorials September 29-30)
https://www.fing.edu.uy/inco/congresos/ifl2025
==========================================================
The goal of the IFL symposia is to bring together researchers actively
engaged in the implementation and application of functional and
function-based programming languages. IFL 2025 will be a venue for
researchers to present and discuss new ideas and concepts, work in
progress, and publication-ripe results related to the implementation and
application of functional languages and function-based programming.
### Registration
The registration fee covers use of facilities, participation in the
tutorials and symposium, lunches, coffee breaks, social outing,
symposium dinner and access to draft proceedings.
Early Bird Registration Deadline is Sep 5, 2025.
https://www.fing.edu.uy/inco/congresos/ifl2025/register.html
If you choose online payment at registration, you will receive payment
instructions during the week.
### Keynote speakers
Roberto Ierusalimschy
Departamento de Informática, PUC-Rio, Río de Janeiro, Brazil
Functions in Lua
Iván Pérez
NASA Ames Research Center, California, USA
Making Haskell Fly
https://www.fing.edu.uy/inco/congresos/ifl2025/keynotes.html
### Tutorials
On September 29 and 30, the two days prior to the symposium, four
tutorials will be held:
Gradual typing
Éric Tanter, University of Chile, Chile
Type Based Static Analysis
Jurriaan Hage, Heriot-Watt University, UK
Development of dApps in the UTxO model
TxPipe, Argentina
Programming-Based Automata Theory
Marco T. Morazán, Seton Hall University, USA
https://www.fing.edu.uy/inco/congresos/ifl2025/tutorials.html
### Accepted Papers
Regular Papers:
Compilation of the Stochastic Language ALEA, Baltasar Trancón Y
Widemann and Markus Lepper.
Design and Implementation of DSLs for Unit Testing, Marco T. Morazán
and Andres Garced.
Recipe-Based Errors: Methodology, Implementation, and Evaluation,
Marco T. Morazán, Shamil Dzhatdoyev, Josephine Des Rosiers, Rose
Bohrer, Andres Garced and David Anthony Fields.
Refinement-Types Driven Development: A study, Facundo Domínguez and
Arnaud Spiwack.
Draft Papers:
AI-Assisted Program Design Using Structural Recursion, Marco T. Morazán.
A Quantum-Control Lambda-Calculus with Multiple Measurement Bases,
Nicolas A. Monzon and Alejandro Díaz-Caro.
Automatic Testing for Finite-State Machines, Marco T. Morazán, Sophia
G. Turano, Andres Garced and David Anthony Fields.
Closures in a Higher-Order Polymorphic DSL for GPU programming, Andre
Rauber Du Bois, Henrique Gabriel Rodrigues and Rodrigo Geraldo
Ribeiro.
Energy-aware Data-Parallel Functional Array Processing for
Heterogeneous Platforms, Clemens Grelck.
Formalizating System I with type Top in Agda, Agustín Séttimo,
Cristian Sottile and Cecilia Manzino.
Foundations of Gradual Abstract Interpretation, Gaspar Ricci,
Sebastian Erdweg, Éric Tanter and Matías Toro.
Heuristics-based Type Error Diagnosis for Haskell: the case of type
families, Niels Kwadijk and Jurriaan Hage.
Higher-ranked region inference for polymorphic, lazy languages, Ivo
Gabe de Wolff and Jurriaan Hage.
Improving a Group Membership Protocol Implementation using Liquid
Haskell and QuickCheck, Jianhao Li and Viktoria Zsok.
List Fold Operators in Dafny, Juan Michelini, Nora Szasz and Alvaro Tasistro.
Reducibility candidates modulo isomorphisms, Cristian Sottile and
Alejandro Díaz-Caro.
Type Checking Dependently Sorted Nominal Signatures, Maribel
Fernandez, Miguel Pagano, Nora Szasz and Alvaro Tasistro.
Unrestricted Grammar Design and Visualization: A Design Recipe and
Dynamic Visualization Tool, Marco T. Morazán, Andres Garced and Tijana
Minić.
========================================================
Haskell Symposium 2025 Call for Talks
Thu 16 - Fri 17 Oct 2025, Singapore
https://conf.researchr.org/home/icfp-splash-2025/haskellsymp-2025
========================================================
The ACM SIGPLAN Haskell Symposium 2025 will be co-located with the 2025
International Conference on Functional Programming (ICFP) and the 2025
International Conference on Systems, Programming, Languages and
Applications: Software for Humanity (SPLASH).
The Haskell Symposium presents original research on Haskell, discusses
practical experience and future development of the language, and promotes
other forms of declarative programming.
We invite proposals from potential speakers for talks. Talk proposals
should report work in progress relevant to Haskell language design, theory,
tools, or applications.
Talks are proposed by submitting an abstract. Please submit a talk title
and abstract of no more than 300 words. There will be no published
proceedings.
Papers should be submitted through HotCRP at: https://haskell25.hotcrp.com/
Submission deadline: 15 September 2025 (Mon)
Deadlines are valid anywhere on Earth.
Talk proposals will go through a lightweight reviewing process, evaluated
by the PC for 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.
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;
* Experience Reports, to document general practice and experience in
education, industry, or other contexts;
* System Demonstrations, based on running software rather than novel
research results.
I’d like to take over Hackage packages https://hackage.haskell.org/package/COrdering and https://hackage.haskell.org/package/AvlTree. Last uploads were in 2008. Both packages fail to compile with modern GHCs; my intention is to bring them back to life.
There are no maintainer contacts and no source code repository linked, so I cannot reach out to the maintainer to offer my services.
Best regards,
Andrew
The GHC developers are very pleased to announce the availability
of the fourth release candidate for GHC 9.10.3. Binary distributions, source
distributions, and documentation are available at [downloads.haskell.org][] and
via [GHCup](https://www.haskell.org/ghcup/).
GHC 9.10.3 is a bug-fix release fixing over 50 issues of a variety of
severities and scopes. A full accounting of these fixes can be found in the
[release notes][]. As always, GHC's release status, including planned future
releases, can be found on the GHC Wiki [status][].
The changes from the third release candidate are:
- A fix for a rare segfault with code involving STM (#26205)
- A fix for the `naturalAndNot` returning bogus results (#26205)
- A fix for a crash in the renamer (#25056)
This release candidate will have a two-week testing period. If all goes well
the final release will be available the week of 1 September 2025.
We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable,
Serokell, SimSpace, the Haskell Foundation, 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.
[release notes]: https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.10/docs/users_guide/9.10.3-…
[status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status
[downloads.haskell.org] https://downloads.haskell.org/ghc/9.10.3-rc4
[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
The GHC developers are very pleased to announce the availability
of the third release candidate for GHC 9.10.3. Binary distributions, source
distributions, and documentation are available at [downloads.haskell.org][] and
via [GHCup](https://www.haskell.org/ghcup/).
GHC 9.10.3 is a bug-fix release fixing over 50 issues of a variety of
severities and scopes. A full accounting of these fixes can be found in the
[release notes][]. As always, GHC's release status, including planned future
releases, can be found on the GHC Wiki [status][].
The changes from the second release candidate are:
- Reverting a change the exports of the `Backtrace` constructor in the base library that was backported
due to confusion on CLC approvals (!14587)
- Reverting a change to the configure script (!14324) that dropped probing for ld.gold
This release candidate will have a two-week testing period. If all goes well
the final release will be available the week of 22 August 2025.
We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable,
Serokell, SimSpace, the Haskell Foundation, 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.
[release notes]: https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.10/docs/users_guide/9.10.3-…
[status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status
[downloads.haskell.org] https://downloads.haskell.org/ghc/9.10.3-rc3
[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
Hello everybody =)
I've been bugged by the silent overflowing of integer parsers as
provided by `base`, `attoparsec`, and others. I'd go so far as to
call it a bug when the user types `298` and the parser says `Right
42`.
Unfortunately, all parsing libraries I've looked at get this wrong. A
[solution][4] is proposed below.
I'm asking for feedback on how to continue from here.
Kind regards
Stefan
The following examples can be reproduced with
$ git clone 'https://github.com/s5k6/robust-int.git'
$ cd robust-int
$ cabal repl robust-int:demo
Situation
---------
This is the current situation with [read][1] from base:
> read "298" :: Word8
42
And with [decimal][2] from attoparsec:
> A.parseOnly (A.decimal :: A.Parser Word8) $ pack "298"
Right 42
And the solution [usually suggested][5] for Parsec (which relies on
`read`):
parsecWord8 :: P.Parser Word8
parsecWord8 = read <$> P.many1 P.digit
> P.runParser parsecWord8 () "" "298"
Right 42
Even worse, the latter would rather exhaust memory than realise its
input is way out of bounds:
> P.runParser parsecWord8 () "" $ repeat '1'
⊥
Also, some 3rd-party libraries get this wrong, e.g.,
[parsec3-numbers][6]:
> P.runParser (PN.decimal :: P.Parser Word8) () "" "298"
Right 42
And [megaparsec][8], which is at least nice enough to warn about this
in its documentation:
> M.parseMaybe (M.decimal :: M.Parsec () String Word8) "298"
Just 42
I find this misses the point of a parser validating its input.
Solution
--------
It is [possible to implement][7] parsers for bounded integral types
which verify the bounds of the parsed value *while* parsing, and even
doing this without the use of a “bigger” type.
The idea is as follows:
As usual, we parse digits left to right, and collect the resulting
value in an accumulator `acc`, i.e., for each new digit `d`, the
accumulator is updated to
base * acc + d
Nothing new up to here. However, before we start parsing, calculate
(lim, m) = upper_bound `divMod` base
and before updating the accumulator with another digit `d`, verify
that
acc < lim || (acc == lim && d <= m)
which exactly guarantees that the accumulator will not overflow. The
reason why this works is is easily seen by doing the example for
`Word16` in base 10:
> (maxBound :: Word16) `divMod` 10
(6553,5)
> 10 * fst it + snd it
65535
Complexity: This adds a modulo operation and two comparisons for every
literal being parsed, plus one comparison for every digit. In order
to limit memory consumption, some comparison has to take place during
parsing, at least for limiting the number of digits consumed. In
total, this does not look too expensive.
I have [implemented][4] this idea for `parsec` and `attoparsec` to
demonstrate the idea (only for decimal values).
What now?
---------
Obviously, this *should not be a another library*, trying to fix some
aspect of some other libraries. My code is rather intended for
demonstration. I'd prefer to help this idea migrate to the libraries
(`base`, `parsec`, `attoparsec`, …), where the correct parsers should
be.
Unfortunately, I got a bit lost when trying to track down the code of
`read` in the `base` package. And I think I may have overengineered
my solution for attoparsec to accommodate different stream types.
Also, I get the impression that Haskell *library* code seems to be
written with a different mindset, a deeper understanding of GHC than
mine, i.e., more tailored to what the compiler will *actually do* when
using the code, trying not to spoil opportunities for optimisation.
And I'm not sure I'm up to that task.
So I'm asking for feedback on the proposed algorithm, my
implementation, and hints on where and how to get this into
established libraries.
Build instructions
==================
$ cabal build
$ cabal run demo
$ cabal test
$ cabal haddock
[1]: https://hackage.haskell.org/package/base-4.21.0.0/docs/Prelude.html#v:read
[2]: https://hackage.haskell.org/package/attoparsec-0.14.4/docs/Data-Attoparsec-…
[3]: https://hackage.haskell.org/package/parsec-3.1.18.0/docs/Text-Parsec-Token.…
[4]: https://github.com/s5k6/robust-int
[5]: https://stackoverflow.com/questions/24171005/how-to-parse-an-integer-with-p…
[6]: https://hackage.haskell.org/package/parsec3-numbers
[7]: https://github.com/s5k6/robust-int/blob/master/src/Data/RobustInt/Parsec.hs…
[8]: https://hackage.haskell.org/package/megaparsec-9.7.0/docs/Text-Megaparsec-C…
--
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.
