为什么一些三便士-gui玻璃钢组合器在MonadIO monad上运行，而不是纯的？

Question

首先是免责声明，由于我对Haskell的了解不是很深入，所以我可能完全误解了threepenny-gui的工作方式，所以对我的断言持保留态度。:-)

在我看来，有些组合子并不是纯粹的，例如：

stepper :: MonadIO m => a -> Event a -> m (Behavior a)

stepper是否必须在某种类型的IO monad上操作(因此它不是纯的)，或者我在这里误解了什么？第二个问题，如果这些组合确实是不纯的，为什么呢？对我来说，这使得构建事件图的代码没有反应式香蕉好得多，因为人们必须使用IO monad，而不仅仅是纯粹的普通函数。代码似乎比反应式香蕉中的代码更复杂。

更可怕的是，valueChange看起来是纯粹来自类型

valueChange :: Element -> Event String

但它实际上是在内部使用unsafeMapIO，所以它实际上是在做隐藏IO吗？再说一次，我可能误解了什么，但这不是Haskell最大的罪过吗？这也很令人困惑，我不能从类型中分辨出回调注册是如何发生的……在哈斯克尔之前我从来没有遇到过这种事。这样做是为了让用户不必处理框架monad吗？

Answer 1

我不是一个三分钱的用户，但是我可以从我阅读的代码中给你一些关于你的问题的信息。

首先关于stepper：似乎在内部threpenny gui使用IORefs来跟踪累积参数。这就是stepper需要MonadIO的原因。然而，我不认为这需要IO来构建您的事件图，它只是意味着它必须在IO中运行。作为API用户，这应该不会给您带来任何不便。如果你认为是这样的，请发一个更具体的问题。

其次，关于valueChange在不安全函数方面的实现:是的，这在Haskell库中很常见。Haskell库的作者经常使用不安全的函数，因为他们知道使用这些函数的方式对于所有可能的执行路径实际上都是安全的，但无法向类型系统证明这一点。换句话说，库作者以一种安全的方式使用不安全的操作，这样您就不必这样做了！

Answer 2

这个答案是对Tom Ellis'的补充。它涵盖了我如何从一个三分钱用户的角度来证明一元FRP组合器的合理性。

有了Threepenny，很有可能你的事件图的很大一部分是由Element构建的，因为它们与浏览器中的DOM绑定在一起，所以它们存在于UI (IO的一个瘦包装器)中。在这种情况下，消除外部插入的间接性是有意义的(就像旧的reactive-banana-threepenny包过去所做的那样)。在reactive-banana-threepenny的情况下，间接性不仅限于必须使用FRP monad，而且还涉及到在不同的事件类型-- reactive-banana和Threepenny之间进行转换(值得考虑的是，Threepenny中的Frameworks是可选的；您也可以以传统的、命令式的方式使用事件)。

总体而言，这是一种权衡:为了消除一些间接性并使API更容易访问，牺牲了定义事件图时的一些整洁性。然而，根据我的经验，这种权衡是值得的。

在结束语中，这个discussion I had with Heinrich大约在从反应式香蕉三便士转向的时候，可能会对这个问题有更多的了解。