【问题标题】:Why does running GHCi in Windows make it not possible to detect infinite loops?为什么在 Windows 中运行 GHCi 会导致无法检测到无限循环?
【发布时间】:2019-06-04 20:05:00
【问题描述】:

我目前正在阅读“Haskell Programming from first principle”,在关于 bottom 的部分中有一段内容如下:

让我们检查一下我们可以在程序中找到底部的几种方法:

Prelude> let x = x in x

*** 例外:>

这里 GHCi 检测到 let x = x in x 永远不会返回,并将永无止境的短路 计算。这是一个底部的例子,因为它永远不会发生 返回结果。 请注意,如果您使用的是 Windows 计算机,则此 示例可能会冻结您的 GHCi 而不会引发异常。

我的问题是:Windows 是否有任何固有的东西使得无法或难以检测到这个循环,或者它只是特定于 GHC(i) 实现?

【问题讨论】:

  • 我相信这与使用单线程运行时还是多线程运行时有关。
  • 您是否明白,一般来说,detect non-termination不可能? Haskell 只在某些偶然的情况下成功,而且它绝对不提供任何关于能够检测到非终止的保证(因为它不能)。
  • 这与Halting problem 本质上是相反的(你可以说它是“循环问题”),尽管对于某些情况有求解器 的停机问题,一般来说是一个不可判定的问题。

标签: windows loops haskell ghc


【解决方案1】:

评论似乎已经过时了。我可以确认在 Linux 上的 GHCi 8.6.4 中,在交互式提示中输入此代码只会挂起。

此外,如果您参加该计划:

main = let x = x in x

并使用 GHC 8.6.4 编译它(再次在 Linux 上),然后在没有优化的情况下编译它挂起,而使用 -O2 编译它会打印:

Loop: <<loop>>

它是否编译线程似乎没有任何区别。

最重要的是,GHC 没有真正保证它可能会或可能不会“捕获”哪些无限循环,这可能会因版本而异,具有不同的优化设置,在交互式代码与非交互式代码中,并且可能因架构而异。

Windows 本身并没有什么东西可以阻止这种检测过程,也没有什么特别的原因会导致程序的 Windows 和 Linux 版本的行为不同。如果评论在某一点上是准确的,那么可能是 Windows 下代码生成的一些细微差异导致了观察到的行为的差异。

【讨论】:

    猜你喜欢
    • 2013-06-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-05-06
    • 2012-09-27
    相关资源
    最近更新 更多