为什么getEvent的类型签名是什么？

Question

UI.NCurses库中getEvent的类型签名具有类型签名

Window -> Maybe Integer -> Curses (Maybe Event)

尽管我一堆使用了此功能，但我仍然不确定Window的用途。文档说了

  

从给定窗口中获取下一个事件。

但这并不能真正启发我（对我而言，阅读源代码同样无济于事）。在我看来，如果发生按键之类的事件，则不会在窗口内发生。实验支持了这一假设，无论我通过什么窗口，我似乎都接受了相同的事件。如果我有几个打开的窗户，如果我一个或另一个通过，会有什么区别？

如果确实使用窗口，为什么类型签名不是更自然

Maybe Integer -> Update (Maybe Event)

Answer 1

通常，Haskell希望将函数的所有“依赖项”作为参数传递。在getEvent的正文中，它多次使用传入的win参数。

面向对象的比喻为window.getEvent(timeout)。但是在FP中，除了参数到函数的顺序外，第一个参数没有什么特别的。

关于如果您通过其他窗口会发生什么，文档会说：

  

从给定的窗口获取下一个“事件”。

因此，大概是在将事件范围限定为作为参数传递的特定窗口。为了进一步与OO类似，这是以下两者之间的区别：

myMainWindow.getEvent(100)
popupWindow.getEvent(250)

也就是说，window的实例不同。

Answer 2

getEvent函数需要一个窗口

Haskell NCurses库写在GNU ncurses库（C库）的顶部。 由于GNU ncurses库对每个窗口都有单独的输入队列，因此getEvent函数需要在调用适当的GNU ncurses例程时知道从哪个窗口获取输入。如果在接收到输入后不立即对其进行处理，则窗口具有单独的输入队列的需求可能会更加明显。

Update monad vs. Window参数？任意

UI.NCurses软件包包含未导出的函数

withWindow :: (Window -> IO a) -> Update a

，正如其类型所暗示的，可用于轻松地将以Window作为输入的函数转换为返回包装在Update monad中的结果的函数。 似乎开发Haskell NCurses库的人只是认为getEvent在大多数情况下以Window作为参数而不是使用Update monad会更好。