问题标签 [unsafe-perform-io]

Haskell 通常被称为纯函数式语言的示例。鉴于 的存在，这怎么能证明是合理的System.IO.Unsafe.unsafePerformIO？

编辑：我认为“纯功能”意味着不可能将不纯的代码引入程序的功能部分。

有一些关于将其作为部门范围内的禁止使用unsafePerformIO及其类似物的政策的讨论。就个人而言，我并不介意，因为我一直认为，如果我发现自己想要使用它，通常意味着我需要重新考虑我的方法。

这个限制听起来合理吗？我似乎记得在某处读过它主要是为 FFI 包含的，但我现在不记得我在哪里读到了。

编辑：好的，那是我的错。它不会在合理需要的地方受到限制，即。FFI。该政策的重点更多地是为了阻止懒惰和代码异味。

我找到了一些示例代码，并对其进行了一些更改

每次运行时返回 1 然后 2 然后 3 然后 3 等等。

但是当我把它改成

然后我每次运行它都会得到 0 。

为什么会发生这种情况，我能做些什么来解决它？

我在 haskell 中编写了一个函数，它接受一些参数，如 Word32、String（忽略柯里化）并输出 IO Word32。现在，这是一个真正意义上的函数：对于相同的输入，输出总是相同的。没有副作用。该函数返回 IO Word32 而不是 Word32 的原因是该函数在一个循环中多次更新许多 32 位线性反馈移位寄存器 (lfsr) 和其他寄存器，以计算最终的 Word32 输出。

我的问题是：鉴于此函数实际上没有副作用，是否可以在函数实现中隐藏这些寄存器更新，以便函数返回 Word32 而不是 IO Word32？如果是这样，怎么做？

我经常在 Haskell 代码中找到这种模式：

基本上，一个人有一个选项记录或类似的东西，最初是在程序开始时设置的。由于程序员比较懒惰，他不想options在整个程序中携带记录。他定义了一个MVar来保持它——通过一个丑陋的使用来定义unsafePerformIO. 程序员确保状态只设置一次，并且在任何操作发生之前。现在程序的每个部分都必须unsafePerformIO再次使用，只是为了提取选项。

在我看来，这样的变量被认为是务实的纯粹（不要打败我）。是否有一个库可以抽象出这个概念并确保变量只设置一次，即在初始化之前不进行任何调用并且不必编写unsafeFireZeMissilesAndMakeYourCodeUglyAnd DisgustingBecauseOfThisLongFunctionName

我试图通过添加对“putStrLn”的调用来获取一个 Haskell 函数，以便在应用它时显示它：

（最终目标是证明为什么一个版本的 isPrime 比另一个版本更有效。）

当我将上面的代码加载到 GHCi 中时，我得到了错误：

无法将预期类型Bool与实际类型匹配m0 b0

我确定这是一个 n00b 错误。有人可以告诉我完成我想做的事情的正确方法吗？

我有一个包含 IORef 作为重要元素的数据类型。这意味着没有一种干净的方法可以使它成为show类型类的成员。这还不错，因为我print在 IO monad 中有一个针对这种类型的函数。但是在 GHCi 中很烦人，因为每次我返回其中一个结果时，我都会收到一个错误，指出它无法显示。

有没有办法让在 IO monad 中运行的 GHCi 使用 IO 动作来显示结果？如果没有，写作会有什么负面影响show a = unsafePerformIO $ print a吗？

下面是一个示例程序的源代码：

当我从 ghci 运行它时， printJob 和 printJob2 都运行良好并将十行写入文本文件。

但是当使用 -threaded 标志编译时，程序只写一行。

我在 ArchLinux 上有 ghc 7.0.3

这是编译命令：

我在做什么错？为什么它在线程模式下不起作用？

编辑：hammar 指出，如果主应用程序早于所有产生的线程退出，那么它们将被杀死并建议在 main 结束时添加延迟。我做到了，正如他预测的那样，它有效。

我最近一直在阅读unsafePerformIO，我想问你一些事情。我对真实语言应该能够与外部环境进行交互这一事实感到满意，因此unsafePerformIO在某种程度上是合理的。

但是，据我所知，我不知道有任何快速方法可以在不检查代码以搜索调用的情况下知道明显纯的（从类型判断）接口/库是否真的纯unsafePerformIO（文档可以省略提一下）。我知道只有在您确定可以保证引用透明度时才应该使用它，但我还是想知道它。

我正在为 C 中的库创建一个 FFI 模块，该库希望在调用其他任何东西之前调用 1 次不可重入函数。这个调用是幂等的，但是是有状态的，所以我可以在每个 Haskell 调用中调用它。但它很慢，并且由于不可重入，它可能会导致冲突。

那么现在是使用 unsafePerformIO 的合适时机吗？我可以将 Bool 包装在不安全的 IORef 或 MVar 中，通过忽略后续调用（全局隐藏 IORef 状态为 False 的调用）来使这些初始化调用具有幂等性。

如果不是，那么正确的方法是什么？