问题标签 [ioref]

我做了以下特定于 IO monad 的函数：

示例用法：

打印“ hello”一次。

我希望（有点恼火）让它适用于尽可能多的情况（不仅仅是在 IO 中）。

我在 hackage 上找到了 stateref，我的代码如下所示：

stateref 是否有替代方法或比我更好的使用方法？

一直让我感到困惑的一件事是现在是否是使用 IORef 的好时机。在决定是否将 IORef 用于任务时，是否应遵循任何准则？什么时候是在 IORef 上使用 State monad 的好时机？

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

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

但是当我把它改成

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

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

我在理解 Haskell 中 IORef 类型和 MVar 类型之间的基本区别时遇到了一些麻烦。有人可以帮我解决这个问题吗？他们似乎解决了同样的问题。MVar 似乎是针对多线程的，但是 IORef 有 atomicModifyIORef 功能。

谢谢！

我正在48 小时内完成为自己编写一个方案（我最多大约 85 小时），并且我已经完成了关于添加变量和分配的部分。本章有一个很大的概念跳跃，我希望它分两步完成，中间有一个很好的重构，而不是直接跳到最终的解决方案。总之……</p>

我迷失了许多似乎服务于相同目的的不同类：State、ST、IORef和MVar. 前三个在正文中被提及，而最后一个似乎是很多 StackOverflow 关于前三个问题的首选答案。它们似乎都在连续调用之间携带一种状态。

它们各自是什么，它们之间有何不同？

特别是这些句子没有意义：

相反，我们使用一个称为状态线程的特性，让 Haskell 为我们管理聚合状态。这让我们可以像在任何其他编程语言中一样对待可变变量，使用函数来获取或设置变量。

和

IORef 模块允许您在 IO monad中使用有状态变量。

所有这一切都使这条线type ENV = IORef [(String, IORef LispVal)]令人困惑——为什么是第二条IORef？如果我改写会破坏什么type ENV = State [(String, LispVal)]？

有代码读取 IORef 并根据一些条件和计算创建一个新值。现在它将新值写入该 IORef。但它有可能根本没有改变。新值可能与旧值相同。

在写入 IORef 之前是否检查值是否不同，或者不管是否只写入 IORef，有哪些注意事项？

writeIORef 是否在设置之前检查值是否已更改？

通过首先检查，您是否可以避免写入并节省一点性能？

我有一个长时间运行的进程forkIO，它会产生像素颜色值：

（其中Color仅包含三个Double值）。

正如预期的那样，当在 的“另一边”读取时IORef，存储的值只是一个 thunk，因此阻塞了主进程。

我知道我需要完全评估[[Color]]头部正常形式的值，但似乎有两种方法可以实现这一点，此外，我不确定如何将它们合并到我的代码中。

我该怎么办？我是否使用rnf,deepSeq或其他一些线程策略？其中一个是首选的，而其他的是否已弃用？它如何适合我的代码？

（PS 请忽略将图像存储为颜色列表的事实是愚蠢的 - 这只是代码的简化版本）。

我怎样才能重构它，以便最终不需要 IORefs？

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

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

设置：

我有几个不同数据结构的集合，它们代表虚拟系统中模拟对象的状态。我还有许多函数可以转换这些对象（即基于原始和 0 个或更多参数创建对象的新副本）。

目标是允许用户选择一些对象来应用转换（在模拟规则内），将这些函数应用于这些对象，并通过用新对象替换旧对象来更新集合。

我希望能够通过将较小的转换组合成较大的转换来构建这种类型的功能。然后评估这个组合函数。

问题：

如何构建我的程序以使这成为可能？

我用什么样的组合器来建立这样的交易？

想法：

1. 将所有的收藏品放在一个巨大的结构中，然后传递这个结构。
2. 使用状态单子完成基本相同的事情
3. 使用 IORef（或其更强大的表亲之一，如 MVar）并建立一个 IO 操作
4. 使用功能响应式编程框架

1 和 2 似乎携带了很多包袱，特别是如果我设想最终将一些集合移动到数据库中。（该死的 IO Monad）

3 似乎运行良好，但开始看起来很像重新创建 OOP。我也不确定在什么级别使用 IORef。（例如IORef (Collection Obj)或Collection (IORef Obj)或data Obj {field::IORef(Type)} ）

4 在风格上感觉是最实用的，但它似乎也创造了很多代码复杂性，而在表现力方面却没有太多回报。

例子

我有一个网上商店。我维护了一系列产品，其中包括（除其他外）库存数量和价格。我也有一些对商店有信誉的用户。

一位用户过来并选择了 3 种产品购买并使用商店信用结账。我需要创建一个新产品系列，减少 3 种产品的库存量，创建一个新的用户系列，并借记用户帐户。

这意味着我得到以下信息：

但后来生活变得更加复杂，我需要处理税收：

然后我需要确保将订单添加到运输队列中：

等等……

我想写的是

但是类型检查器会让我中风。我如何构建这个商店，使checkoutorapplyUserCredit函数保持模块化和抽象？我不可能是唯一一个有这个问题的人，对吧？