Haskell 2010语言报告修订版

# 修订版 Haskell 2010 语言报告 | Haskell 编程语言博客 来源：https://blog.haskell.org/revised-haskell-2010-report/ ## 修订版 Haskell 2010 语言报告 (https://blog.haskell.org/revised-haskell-2010-report/) David Binder (https://blog.haskell.org/authors/david-binder/)2026 年 8 月 4 日\[生态系统 (https://blog.haskell.org/categories/ecosystem/)\] \#haskell\-2010 (https://blog.haskell.org/tags/haskell-2010/)Haskell 2010 语言报告发布至今已将近整整 16 年，尽管人们进行了各种尝试，却始终没有发布新的报告。但这并不意味着语言本身没有变化。恰恰相反，我们今天编写的 Haskell 与 16 年前相比已经大不相同，在这个过程中，这门语言变得更加优美、一致和易用。遗憾的是，语言规范没能跟上这些变化。 我们社区中的许多成员对能否发布新报告持悲观态度。当然，他们也很希望看到一份新的、更新过的报告，但他们认为这要么太难，要么不值得付出努力。我认为这种看法是不对的。拥有一份最新的报告对我们社区的健康至关重要，而且我们实际上完全可以在合理的时间和精力投入内实现这一目标。以下是我关于如何实现这一目标、以及如何在新年之前完成整个过程的计划。 ## 为什么我们需要一份新报告 Haskell 语言报告是语言文档中不可或缺的一部分。对于初学者学习 Haskell 来说，它不是首先应该查阅的资料，但对于那些想要进阶为中级或经验丰富的 Haskeller 的人来说，它是一份重要的资源。如果你想了解浮点字面量的精确语法、do 记法的规则和脱糖方式，或者`default`声明的含义，报告就是你可以找到答案的权威资源。因此，如果你在报告中找到的答案是错误的，或者与编译器实现或 base 库提供的功能不一致，那就很不幸了。在这种情况下，你不得不追溯那些导致当前状态的提案和讨论：Functor\-Applicative\-Monad (https://wiki.haskell.org/Functor-Applicative-Monad_Proposal)、MonadFail (https://gitlab.haskell.org/haskell/prime/-/wikis/libraries/proposals/monad-fail)、Foldable\-Traversable (https://wiki.haskell.org/Foldable_Traversable_In_Prelude) 和 Monad\-of\-no\-return (https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of-no-return) 提案无疑让这门语言变得更好，但它们也让那些想在报告中寻找答案的程序员不得不变成被动的 Haskell 历史学家。 如果语言报告是你唯一可用的 Haskell 资源，那么你编写的任何非平凡的 Haskell 2010 程序几乎肯定无法与 GHC 或 MicroHS 等现代编译器兼容。我们可以，也应该修复这个问题。 ## 如何正确权衡成本与收益 编写一份新报告需要大量工作，我们希望避免重蹈之前编写报告时遇到的问题。因此，重要的是我们要设定一个既可实现、又能为 Haskell 社区带来实实在在好处的目标。最明显的此类目标是从一份**修订版 Haskell 2010 语言报告**开始： - 修订版报告是完全可实现的：我们在用户指南中记录在案的差异列表非常明确（GHC 用户指南：Bugs and Infelicities (https://downloads.haskell.org/ghc/latest/docs/users_guide/bugs.html)）。这些列出的差异大多已经在导致这些差异的已接受提案中得到了充分记录。 - 我们必须实施的更改都不太可能引起争议：它们反映的是我们今天已经在编写的 Haskell。由于所需的更改没有争议，我们可以在编制修订版报告时使用轻量级的决策过程。 - 对社区有明确的好处：我们最重要的参考文档不再过时。我们可以放心地让人们参考 Haskell 报告，而不必警告他们要避开报告中那些不再成立的部分。 - 由于我们没有定义带有新功能集的新 Haskell 版本，而只是修订以前的报告，因此不会对生态系统或编译器编写者造成任何动荡。借鉴托尔金在构思出《指环王》故事后重写《霍比特人》的做法，我们可以对报告进行retcon (https://en.wikipedia.org/wiki/Retroactive_continuity)，并假装修订版报告就是我们一直说的`Haskell2010`。然后，我们就可以简化 GHC 用户指南，删除其中记录与现有报告相比不足之处的大部分第 16 节。 所以，这就是我们可以为自己设定的目标：每一个根据修订版 Haskell 2010 语言报告有效的程序，都将被 MicroHS 和使用`Haskell2010`语言版本的 GHC 接受。 ## 让我们谈谈技术细节 在阐述了动机和目标之后，让我们讨论一些在编写报告、构建报告以及生成最终 PDF 和 HTML 文档时的技术细节。 Haskell 2010 语言报告同时提供 PDF 和 HTML 格式，没有明显的好理由去改变这一点。对于像 Haskell 报告这样复杂且篇幅很长的文档，如果使用正确的创作技术，工作起来会充满乐趣；如果使用不当，则会非常艰难（使用错误的工具和包编译较长的 PDF 可能需要几分钟！），错误信息晦涩难懂，脚本和编程模型也很棘手。 之前版本的 Haskell 报告是使用命令行工具（`sed`、`awk`、`perl`、`make`）、一个用于预处理自定义`\.verb`文件格式的词法/语法分析器、用于编译 PDF 的`pdflatex`以及用于生成 HTML 的`tex4ht`组合编写的。在 2026 年，我们可以使用 2010 年时还不存在的技术，从而大大简化报告的编写过程。在现有技术中，Typst (https://typst.app/) 排版系统目前最能满足这些约束条件： - 它是开源软件，采用 Apache 2.0 许可证。（一个类似 Overleaf 的关联云服务是专有的，但完全可以不使用。） - Typst 用 Rust 实现，编译速度大约比 tex 快一个数量级。这使得在编写报告时可以即时获得视觉反馈。 - 原生支持 PDF 和 HTML 输出，无需使用单独的工具。 - 编译器会输出非常出色的错误信息，并能精确指向代码中的错误位置。 - 更简单的技术（如纯 Markdown）也支持多种输出格式，但它们缺乏生成高质量技术文档所需的高级功能，尤其是在数学排版和复杂图形方面。 使用 Typst 意味着我们必须将报告从自定义的`\.verb`格式转换为`\.typ`文件；幸运的是，这部分工作已经完成，现在只需一个简单的`typst compile`命令就可以编译报告。（转换过程没有涉及 LLM，而是手动完成的，并借助了一些`sed`和`awk`技巧来加速过程。）重新排版 BNF 文法也使其支持超链接：现在可以通过点击非终结符来浏览文法，并跳转到其定义。 ## 记录标准库 现有的 Haskell 2010 报告由两部分组成：第一部分记录语言的语法和语义，第二部分记录标准库。记录标准库是报告的重要组成部分，因为语言的许多方面只能通过库中提供的函数、类型和类型类来定义。例如，数字字面量是多态的，必须根据数字层级来定义；do 记法必须根据 Monad（和 MonadFail）类型类来定义；外部函数接口（FFI）大量使用了`Foreign\.\*`命名空间中定义的函数和类型。 以纯文本形式（无论是 LaTeX 还是 Typst 文件）维护数百页的标准库文档，并确保它们保持有效的 Haskell 且彼此一致，是非常困难的。如果我们想避免错误和不一致悄悄溜进报告，如果我们想保持库规范的可维护性，那么我们就必须以一种适合机器检查的形式来组织它。显而易见的解决方案是使用 Haddock 来记录标准库的 API。修订版报告的仓库包含一个 cabal 包，它公开了 Haskell 2010 语言报告中规定的精确 API。（这个包只规定公共 API：函数和方法本身没有实现。一个可能的延伸目标可能是使用像`api\-diff`或`print\-api`（链接 (https://discourse.haskell.org/t/maintain-a-golden-test-of-your-packages-api-with-diff-package-api-and-print-api/9997)）这样的工具，来确保像`base`这样的包所公开的 API 是报告中定义的 API 的严格超集。） ## 我们应该采用什么流程 Haskell Prime 流程结合了邮件列表讨论和收集 RFC 的 Git 仓库。值得注意的是，该流程并不直接作用于用于构建报告的实际源代码。我们可以通过切换到一种更接近我们开发代码方式的协作流程来减少大量开销：对报告的更改应主要以对报告文本源本身的 pull request 形式进行讨论。组织报告撰写的仓库现在已经公开：github\.com/haskellfoundation/haskell\-2010\-revised\-report (https://github.com/haskellfoundation/haskell-2010-revised-report)。请开始贡献吧：讨论现有 issue、提交新 issue，以及帮助修复技术基础设施方面的问题。我们暂时还不会合并任何对报告的实际更改，因为这些更改需要得到即将成立的新语言委员会的确认，但我们可以开始处理所有其他技术问题。 ## 行动号召 为了使修订版 Haskell 2010 报告获得社区的广泛支持，我们在 Haskell 基金会 (http://haskell.foundation) 的框架下成立了一个新的工作组 (https://gitlab.haskell.org/hf/meta/-/blob/main/working_groups/revised-haskell-2010-report.md)。我们现在需要你的帮助和参与，理想情况下，你可以决定成为负责编制修订版报告的工作组成员。如果你不想成为工作组成员，你仍然可以加入仓库中的所有讨论、提交 issue、并通过 pull request 提出对报告的修改，但成为成员赋予你投票权，决定哪些修改应该被采纳。 我们很快将在 Haskell Discourse (https://discourse.haskell.org/) 上宣布招募工作组成员，随后不久将开始修订版报告的工作。如果你一直希望 Haskell 能有一份新报告，或者因为标准化方面缺乏进展而感到沮丧，现在就是你贡献的机会！有了上面设定的明确范围，我们也可以确信终点线已经清晰可见。谁知道呢，如果修订版报告取得了明显成功，我们也许还会有雄心去追求更宏大的目标……