IO Monad采用动态类型语言

Mys*_*tor 5 monads haskell functional-programming dynamic-typing

在Haskell中,我觉得非常漂亮的一件事是它使用Monads作为有效行为的抽象.它创建了一种非常优雅的方式来表达命令式代码,同时还允许强大的事情发生并保证正确性.

IO monad似乎并不特定于强类型语言.具体来说,在我看来,用动态类型语言实现IO monad并不困难或没有革命性.然后,只需要限制语言,以便所有IO操作只是在IO monad中生成动作.

话虽这么说,我还没有看到任何动态类型的语言(也许我只是看起来不够努力),但使用monads隔离副作用.是否有这种情况的原因?(或它们存在吗?)

Car*_*arl 12

你在这里混淆了两个问题.我不能因此而责怪你,因为关于Haskell的大部分文献也将这两个想法混为一谈.但是,类型化IO是Haskell方法的神奇之处.IO类型形成monad的事实并不那么重要.它只是意味着它可以与其他类型共享库函数,而不是重新实现它们本身.

monad抽象在动态类型语言中并不能很好地工作.当然,他们可以给你模拟fmap(>>=),但没有好的方法return来使用动态类型的语言.它在类型变量中是多态的,仅在其返回类型中出现.我不知道有任何动态类型的语言能够很好地处理它.我想有可能用自由monad构造和大量内省来破解它,但我怀疑它看起来像是一个有用的抽象.

另一部分,类型IO,可能可以集成到动态语言中.显然它会成为运行时标记的IO,而不是类型化的IO.但是,必须建立关于语言的一切以支持它.程序执行的入口点必须指定为IO值,而不是像大多数动态语言选择的那样只执行文件中每一行的常用习惯用法.然后你必须使用组合器或语法来组合IO值,就像在Haskell中一样.最后,你必须忍受声称语言难以使用的用户,因为它与他们习惯的语言不同.

真的,这是最后一个杀手.

  • 嗯,Clean使用基于IO唯一性类型的系统.我想你可能会发现任何适用于类型IO的抽象大致相当于monadic组合器.我的真正观点是那些组合器不是IO类型的特殊部分.它们只是方便的管道运算符,恰好可以在Haskell的类型系统中以多态方式定义. (3认同)