玻璃钢是实现大多数“事件驱动”事物的正确方式吗？

Question

在我对Haskell的第一印象中，这是一种语言，能够很好地处理“执行-然后结果”的事情。但是我找不到如何实现“事件驱动”的东西，比如游戏，或者HTTP/FTP/TCPSocket服务器。

这个问题是在我看了一些关于玻璃钢的文章后才被回答的，包括雅帕和它创建的FPS游戏( 破骨 )。看起来，玻璃钢是一个很好的模型来实现“重”事件驱动的东西，如3D游戏，但更轻的事件驱动应用程序，如HTTP服务器或普通桌面GUI程序呢？如果我用玻璃钢来实现所有这些事情，会出现什么缺点？

Answer 1

玻璃钢是一种非常普遍的技术，几乎可以肯定地被用来实现任何正常使用事件的东西。在玻璃钢的经典再现中，事件是其核心抽象之一。不同之处在于，您不是单独使用回调对事件进行操作，而是对事件流进行操作。

您应该能够以事件流的形式呈现任何正常的事件驱动代码；唯一的困难是将您的流绑定到现有的外部代码(如GUI工具包)中；然而，这要比复杂得多。所以我看不出有什么根本的问题阻止你在任何地方使用玻璃钢，你可以用不同的语言进行活动。

事实上，我有过一些很好的使用玻璃钢的经验，你称之为“打火机”：简单的GUI程序。我使用活性香蕉和wxWidgets编写了一些非常简单的图形化程序。我发现与等效的基于回调的代码相比，生成的代码更简单、更易于编写和更易于阅读。

反应性香蕉也可以用于像音乐这样的东西，因此它显然是广泛适用的。除了用它进行GUI编程之外，我什么也没有尝试过，但是其他人也尝试过，所以它必须是可能的。

此外，您应该查看Elm，这是一种ML风格的语言，用于使用FRP实现web应用程序。它生成所需的一切: HTML、CSS和JavaScript。我相信它甚至可以处理与服务器的通信。我还没试过，但看起来很漂亮。

因此，人们显然在广泛的领域使用玻璃钢，包括那些不“重”的领域。但这并不意味着你应该在任何地方使用它！

首先，它有可能得到不可预测的时空行为。我知道，反应型香蕉和榆树的创造者都付出了很大的努力来减少这些风险，但我怀疑仍然存在一些风险。我知道我在玩被动香蕉WX时有一些非常奇怪的空间泄漏，所以这肯定是值得注意的事情。与你习惯使用的事件驱动代码相比，用玻璃钢来处理这些可能要困难得多。当然，我有无法解释的内存泄漏与标准的JavaScript，所以非玻璃钢代码也不能幸免！

另一个考虑因素是，对于您的特定任务，FRP可能不是最好的或最清晰的抽象。虽然它很适合那些必须完全反应的东西，但是对于非常简单的代码，比如web服务器呢？(我的意思是简单，因为不同的请求可能不会交互得太紧密。)我认为使用基于FRP的编程模型来处理大量请求的web框架是可能的；我只是不认为这是最优的。

事实上，我的理解是GHC IO系统实际上已经是由事件驱动的，所以您可以用标准的编程风格编写web服务器，并免费使用事件。因此，对于web服务器代码来说，更简单的底层抽象可能是更好的选择。我相信这就是像Snap和Yesod这样的现有框架所做的--它们都没有使用反应式的编程风格，但两者都很容易使用。

Answer 2

您不需要使用“简单”Haskell以外的任何东西来实现事件驱动的游戏。我目前正在使用Haskell编写一个FPS，具有以下(非常高级别)的“体系结构”：

uiMake :: IO ([UIEvent],UIState)
uiTick :: UIState -> [ApEvent] -> IO ([UIEvent],UIState)

apMake :: ([ApEvent],ApState)
apTick :: ApState -> [UIEvent] -> ([ApEvent],ApState)

-- UIState = The state of the UI
-- ApState = The state of the application (game)
-- UIEvent = Key presses, screen resolution changes etc.
-- ApEvent = Entity movements etc.

效果很好。不需要镜片，玻璃钢或任何其他“异国情调”。