为什么在Windows上运行GHCi会导致无法检测无限循环？

Question

我目前正在阅读《Haskell编程入门》这本书，其中在关于bottom的章节中有一段话：

Let us examine a few ways by which we can have bottom in our programs:

Prelude> let x = x in x

*** Exception: << loop >>

Here GHCi detected that let x = x in x was never going to return and short-circuited the never-ending computation. This is an exam- ple of bottom because it was never going to return a result. Note that if you’re using a Windows computer, this example may freeze your GHCi and not throw an exception.

我的问题是：Windows是否存在任何固有的障碍，使得检测此循环变得不可能或困难，还是只适用于GHC(i)实现？

- Christian

---

我认为这与使用单线程运行时还是多线程运行时有关。 - melpomene

你是否明白通常情况下无法 检测非终止？Haskell只在某些偶然的情况下成功，它绝对不能提供任何关于能够检测非终止的保证（因为它无法实现）。 - Andrej Bauer

这本质上是 停机问题 的相反（你可以说它是“循环问题”），虽然有一些特定情况下的停机问题求解器，但总体来说它是一个不可判定的问题。 - Willem Van Onsem

Answer 1

评论似乎已经过时。我可以确认在Linux上的GHCi 8.6.4中，将这段代码输入交互提示符中只会导致程序挂起。

此外，如果您使用以下程序：

main = let x = x in x

如果您在Linux系统上使用GHC 8.6.4编译相关内容的代码，不开启优化选项会导致程序卡死，而开启-O2优化选项则会输出以下结果：

Loop: <<loop>>

无论是否编译为线程，似乎都没有什么区别。

归根结底，GHC并不会对可能或不可能“捕获”的无限循环做出真正的保证，这可能会因版本不同、优化设置不同、交互式与非交互式代码以及架构不同而发生变化。

在Windows中没有任何固有的东西会阻止这个检测过程，也没有特别的理由可以解释为什么程序的Windows和Linux版本会有不同的行为。如果该评论曾经是准确的，那么它可能是由于在Windows下的代码生成中存在微妙的差异导致观察到的行为差异。

- K. A. Buhr