在处理尴尬小队：Haskell 中的 monadic 输入/输出、并发、异常和外语调用中，SPJ 指出：
例如，函数程序可能是一个将输入字符串映射到输出字符串的函数：
main :: String -> String现在，用（喘息！）C 编写的“包装器”程序可以从某处获取输入字符串 [...] 将函数应用于它，并将结果存储在某个地方 [...]
然后他继续说这定位了包装器中的“罪孽”，并且这种方法的问题在于一个罪孽导致另一个罪孽（例如多个输入、删除文件、打开套接字等）。
这对我来说似乎很奇怪。我会认为 Haskell 会是最强大的，甚至可能是最有用的，当完全以这种方式接近时。即输入是位于文件中的字符串，输出是新文件中的新字符串。如果输入字符串是一些与数据连接的数学表达式，而输出字符串是（非 Haskell）代码，那么您可以完成任务。换句话说，为什么不总是将 Haskell 程序视为翻译器？（或者作为编译器，但作为翻译器，您可以将真正的 I/O 混合到最终的可执行文件中。）
不管将其作为一般策略是否明智（我意识到我们可能想要完成的某些事情可能不是从数学开始的），我真正的问题是：如果这确实是方法，我们可以避免这种IO a类型吗？我们是否需要其他语言的包装器？真的有人这样做吗？
那个包装器存在。它被称为Prelude.interact。我Data.ByteString经常使用它的版本。纯String -> String函数的包装器有效，因为字符串是惰性求值的单链表，可以在读入时处理每一行输入，但 UCS-4 字符的单链表是一种非常低效的数据结构。
您仍然需要使用IO包装器，因为操作取决于宇宙的状态，并且需要与外部世界进行排序。特别是，如果您的程序是交互式的，您希望它立即响应新的键盘命令，并按顺序运行所有操作系统系统调用，而不是（例如）处理所有输入并在准备好时立即显示所有输出退出程序。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句