Haskell 生态周报（2026-07-08 至 07-15）：GHC 9.12.5 状态待确认，工具链与社区项目继续更新

先看结论

截至 2026 年 7 月 15 日 16:00（Asia/Shanghai），GHC 9.12.5 仍不能在本期写成「已发布」。6 月 24 日的官方社区公告确认的是 ghc-9.12.5-rc2，公告给出的计划是：测试两周，顺利的话在 7 月 8 日当周发布正式版。1

本周的构建基线也还停在 GHC 9.12.4：Stackage Nightly 2026-07-13 使用的 resolver 是 nightly-2026-07-13，对应 ghc-9.12.4。Haskell.org 的 GHC 主页目前列出的最新新闻仍是 3 月 27 日发布 GHC 9.12.4。两条信息不能证明正式版一定没有发布，但足以说明升级状态还没有形成一条清晰、可复现的公开链路。2 3

GHC 9.12.5：候选版带来了什么

rc2 是 bug-fix 版本，公告列出的修复方向包括 POSIX 平台上的 -jsem jobserver semaphore protocol v2、pattern match checker、demand analyser、ticks 与 coercions 的交互，以及 blackholes。1

升级时有一条实际影响：本次版本把 semaphore-compat 升到 v2，公告说明 semaphore 功能需要 cabal-install 3.18 或更高版本才能恢复正常。也就是说，测试 GHC 9.12.5-rc2 时，不能只替换编译器，构建工具版本也要一起核对。1

对日常开发而言，本期更稳妥的做法是把 9.12.5 当作待确认的升级目标：需要测试新版本的项目可以单独建 CI 矩阵，生产环境则继续以当前 resolver 和已验证的 cabal-install 组合为准。Stackage 在 7 月 13 日仍使用 GHC 9.12.4，这个信号比一条「预计发布」更适合拿来做今天的默认配置。2

一个仍在讨论的 GHC 提案

Haskell Discourse 上的 memo-io 讨论，试图处理顶层共享可变状态这个长期问题。提案作者认为，OPAQUE 比 NOINLINE 更适合支撑这种惯用法；在编译器遵守修饰符的前提下，类似 foo :: %TopLevelIO (IORef Int); foo = newIORef 0 的写法可以保持语义安全。作者也指出，仍会失去与其他 IO action 的排序保证。4

讨论没有停在语法层面。回复中有人追问 CSE 发生的具体例子，也有人问是否可以用 thread-local state 解决同一类需求。这个提案目前应当看作正在讨论的编译器与语言设计方案，不是已经接纳的 GHC 特性。4

库与工具链

`warp` 3.4.14

Hackage 页面显示，基于 WAI 的 HTTP/1.x 与 HTTP/2 服务器库 warp 在 7 月 11 日上传了 3.4.14，页面报告的构建状态是 InstallOk。它依赖 wai、http2、network、bytestring、text、time 和 x509 等包，适合当作近期网络服务栈的一个小而具体的更新观察点。5

`vscode-haskell` 2.8.2

HLS 团队发布的 vscode-haskell 2.8.2 是一个小版本，主要回应此前关于 VS Code 扩展包的讨论：它把 haskell.language-haskell 加入主扩展，作为 extension pack。用户如果偏好其他语法高亮扩展，可以移除这个依赖。6

这类改动不改变编译器，却会直接影响新项目的安装体验。对刚开始使用 Haskell 的读者来说，编辑器扩展、HLS、GHC 和构建工具必须能一起工作，才算完成一次工具链更新。

社区在谈什么

Haskell Weekly 第 532 期发布于 7 月 9 日，选题很能说明近期社区的分布：一边是 Haskell MOOC 的 Applicatives 教程、SICP 数据导向编程和 typed expression EDSL，另一边是 Haskell Ecosystem Workshop 2026 的 GHC 构建速度演讲、ZuriHac 2026 视频播放列表，以及在浏览器 WebAssembly 中运行的 Haskell CAD playground。7

值得收藏的是 ZuriHac 播放列表。公告计划从 7 月 10 日开始，持续到大约 9 月 18 日，每周五发布一条或多条活动视频。它不是一次性发布的新闻，而是接下来几个月持续补充的社区学习资料。7

Reddit 的 r/haskell 本周出现了两个方向不同的项目消息。

PGQueuer-hs 0.0.1 是一个 PostgreSQL 原生的任务队列 MVP，使用数据库的 LISTEN / NOTIFY 通道，不依赖 Redis 或 RabbitMQ；它宣称与 Python 的 pgqueuer 100% 兼容，可以让 Python 生产任务、Haskell worker 消费任务。当前实现基于 postgresql-simple，作者提醒 API 仍可能调整。8
Scarf 的作者 Avi Press 在 7 月 10 日写道，产品经过 7 年生产使用后，新的 API 工作将改用 Python，并逐步缩小 Haskell 代码面。他把编译时间、生态摩擦和冷启动成本列为自身场景中的主要原因，同时明确说这不是对整个行业的统计结论。9

第二条消息值得读，但不适合被压缩成「Haskell 不适合生产」这种结论。它更具体地暴露了一个工程问题：当开发流程变成多个 agent、多个 worktree 和频繁冷启动时，编译速度、缓存、Nix、CI 和文档会一起进入语言选择的成本账单。这个问题和 Haskell Weekly 同期收录的 GHC 构建速度演讲，正好形成了同一周的两面。7 9

GitHub Trending 的 Haskell weekly 榜单中，靠前项目包括 SimpleX、Pandoc、ShellCheck、Monoscope 和 Agda。本周新增 star 数分别为 593、142、57、53 和 4。这个榜单混合了成熟项目、工具和用 Haskell 编写的其他语言项目，不应当当作「本周新发布的 Haskell 项目」榜单。10

更有用的读法是看项目类型：SimpleX、Pandoc 和 ShellCheck 说明 Haskell 仍然出现在隐私通信、文档转换和开发者工具这些长期运行的产品里；Monoscope 的描述则把日志、追踪、指标和自然语言查询放在一起，显示 Haskell 项目也在接近当下的可观测性工作流。榜单数字是一次快照，不能替代项目自身的发布记录。10

下周继续盯的三件事

GHC 9.12.5 是否出现正式发布公告，以及对应的 GHCup、Cabal 和 Stackage resolver 更新。
memo-io 是否补充可复现案例，讨论会不会从 NOINLINE / OPAQUE 的惯用法推进到正式 GHC proposal。
构建速度和开发体验是否出现可操作的改进，尤其是 GHC 构建、HLS、编辑器扩展和冷启动缓存之间的组合效果。

References

1
GHC 9.12.5-rc2 公告
discourse.haskell.org
2
Stackage Nightly 2026-07-13
stackage.org
3
GHC 官方主页
haskell.org
4
memo-io：替代 thread 的顶层 IO 提案
discourse.haskell.org
5
warp 3.4.14
hackage.haskell.org
6
vscode-haskell 2.8.2 公告
discourse.haskell.org
7
Haskell Weekly 第 532 期
haskellweekly.news
8
r/haskell：PGQueuer-hs 0.0.1
reddit.com
9
Scarf 迁离 Haskell 的原文
avi.press
10
GitHub Trending Haskell weekly
github.com

先看结论

GHC 9.12.5：候选版带来了什么

一个仍在讨论的 GHC 提案