为什么我们需要IO？

在"解决尴尬的小队:Haskell中的monadic输入/输出,并发,异常和外语调用"中,SPJ指出

"也许函数程序可以是将输入字符串映射到输出字符串的函数:

main :: String - > String

现在用(gasp!)C编写的'包装器'程序可以从某处获取输入字符串..将函数应用于它,并将结果存储在某处......"

然后他继续说这在包装器中定位"罪恶",并且这种方法的问题在于一个罪导致另一个(例如多个输入,删除文件,打开套接字等).

这对我来说似乎很奇怪.我本以为Haskell在以这种方式接近时会是最强大的,甚至可能是最有用的.也就是说,输入是位于文件中的字符串,并且输出是新文件中的新字符串.如果输入字符串是与数据连接的某个数学表达式,并且输出字符串是(非Haskell)代码,那么您可以完成Get Things.换句话说,为什么不总是将Haskell程序视为翻译？(或者作为编译器,但作为翻译器,您可以将真正的IO混合到最终的可执行文件中.)

无论作为一般策略的智慧如何(我欣赏我们可能想要完成的一些事情可能不是从数学开始),我真正的问题是:如果这确实是方法,我们可以避免IO类型吗？我们需要其他语言的包装器吗？有人真的这样做吗？

关键是这String -> String是一个相当差的模型,一般是什么程序.

如果您正在编写一个接受并发流水线请求的http服务器并同时响应每个管道,同时还要交错管道中的响应写入以及下一个请求的读取,该怎么办？这是http服务器工作的并发级别.

也许,只是也许,你可以把它塞进一个String -> String程序.您可以将管道多路复用到单个通道中.但超时怎么样？Web服务器超时连接,以防止慢速loris攻击.你怎么会考虑到这个？也许你的输入字符串有一系列定期添加的时间戳,无论其他输入如何？哦,但接收者只能通过滴漏从接收缓冲区中读取的变体呢？你怎么能告诉你被阻塞等待发送缓冲区流失？

如果你追求所有潜在的问题并将它们填充到一个String -> String程序中,你最终会得到几乎所有存在于haskell程序之外的服务器的有趣部分.毕竟,必须要做多路复用,必须做错误检测和报告,必须做超时.如果你在Haskell中编写一个http服务器,那么如果它实际上是用Haskell编写的话会很好.

当然,这并不意味着IO当前存在的类型是最好的答案.可以提出合理的投诉.但它至少可以让你解决Haskell中的所有问题.