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.
POPL 2026 CALL FOR TUTORIALS
https://popl26.sigplan.org/track/POPL-2026-tutorials#Call-For-Tutorials
The 53rd ACM SIGPLAN Symposium on Principles of Programming Languages (POPL
2026) will be held in Rennes, France.
POPL provides a forum for the discussion of fundamental principles and
important innovations in the design, definition, analysis, transformation,
implementation, and verification of programming languages, programming
systems, and programming abstractions.
Tutorials for POPL 2026 are solicited on any topic relevant to the POPL
community. We particularly encourage submissions of introductory tutorials
that make the research presented at POPL more accessible to the
participants.
Tutorials will be held on Jan 11–13, 2026. The expected length of a
tutorial is 3 hours, including questions and discussion (Q&A).
Submission details
Deadline for submission: October 10th, 2025
Notification of acceptance: October 24th, 2025
A tutorial proposal should provide the following information:
- Tutorial title
- Presenter(s), affiliation(s), and contact information
- 1-3 page description (for evaluation). This should include the
objectives, topics to be covered, presentation approach, target audience,
prerequisite knowledge, and if the tutorial was previously held, the
location (i.e. which conference), date, and number of attendees if
available.
- 1-2 paragraph abstract suitable for tutorial publicity.
- 1-paragraph biography suitable for tutorial publicity.
Proposals must be submitted by email to Robert Rand (rand(a)uchicago.edu) and
Alan Schmitt (alan.schmitt(a)inria.fr) with the subject line "POPL 2026
Tutorial Proposal: [tutorial name]". The proposal should be attached as a
PDF, docx, or txt file.
Further information
Any questions regarding POPL 2026 tutorials should be addressed to the
workshops chairs, Robert Rand (rand(a)uchicago.edu) and Alan Schmitt
(alan.schmitt(a)inria.fr)
The GHC developers are very pleased to announce the availability
of the second 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 first release candidate are:
- Bumping the text submodule to 2.1.3
- Reverting a bug fix (!14291) that restricted previously allowed namespace specifiers (#26250)
- Reverting the bump of the deepseq submodule to 1.5.2.0 (#26251)
This release candidate will have a two-week testing period. If all goes well
the final release will be available the week of 19 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-rc2
[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
I'd like to update the search path of a Haskell module, using the OPTIONS_GHC pragma.
>From the documentation[0], OPTIONS_GHC allows you to set dynamic flags, which `-i` appears to be.[1]
Here's a quick demo of what I believe _should_ work, but doesn't:
A.hs:
{-# OPTIONS_GHC -isrc #-}
import B
main = print b
src/B.hs:
module B where
b = "!"
`ghc A.hs` fails, but (of course) `ghc -isrc A.hs` succeeds. Is there a way to get this to work? Is the current behavior intended? Is what I want a misfeature? (E.g. there are security implications?)
Thanks,
Tom
[0] https://downloads.haskell.org/ghc/latest/docs/users_guide/using.html#comman…
[1] https://downloads.haskell.org/ghc/latest/docs/users_guide/flags.html#findin…
I notice that as late as May 2023, PDF versions of the GHC Users Guide have been available, e.g. https://downloads.haskell.org/ghc/9.2.8/docs/ . For more recent versions, I can't find them anywhere. "Documentation" on the GHC homepage now links only to the HTML version.
Has the team decided to stop pre-rendering a PDF version? That would be a shame; in some contexts a PDF is much more useful than HTML.
(Btw: the GHC man page still links to https://downloads.haskell.org/ghc/latest/docs/users_guide.pdf, which is now a 404 - as is the HTML link)
Thanks,
Tom
The GHC developers are very pleased to announce the availability
of the 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][].
This release candidate will have a two-week testing period. If all goes well
the final release will be available the week of 11 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-rc1
[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
