考虑到unsafePerformIO,Haskell真的是一种纯粹的功能语言吗？
Ste*_*idt 44 haskell type-systems functional-programming referential-transparency unsafe-perform-io
Haskell通常被引用为纯函数式语言的示例.鉴于存在,这怎么可能是合理的System.IO.Unsafe.unsafePerformIO？
编辑:我认为"纯功能"意味着不可能将不纯的代码引入程序的功能部分.
Don*_*art 116
语言我们称之为Haskell
unsafePerformIO是外部函数接口规范的一部分,而不是核心Haskell 98规范.它可用于执行不会逃避某些范围的局部副作用,以暴露纯粹的功能接口.也就是说,当类型检查器无法为我们执行时,我们使用它来隐藏效果(与ST monad不同,它隐藏了静态保证的效果).
为了准确地说明我们称之为"Haskell"的多种语言,请考虑下面的图像.每个环对应于一组特定的计算特征,按安全性排序,并且区域与表达能力相关(即,如果您具有该特征,则可以编写的程序数).
称为Haskell 98的语言在中间指定,允许全部和部分函数.Agda(或Epigram),只允许全部功能,甚至不那么富有表现力,但"更纯粹",更安全.虽然我们今天使用的Haskell包含FFI的所有内容,其中unsafePerformIO存在.也就是说,你可以在现代的Haskell中编写任何东西,但是如果你使用来自外环的东西,那么内环就很难建立安全和安全保证.
因此,Haskell程序通常不是从100%引用透明的代码构建的,但是,它是默认情况下唯一适用的中等语言.
- @Stefan Schmidt:更像是"Haskell*是*纯函数式",但"GHC是一个超级Haskell集的实现,包括外部函数接口,它不是纯粹的功能" (24认同)
Nor*_*sey 34
我认为"纯功能"意味着不可能引入不纯的代码......
真正的答案是,unsafePerformIO它不是 Haskell的一部分,更不用说,垃圾收集器或运行时系统是Haskell的一部分. unsafePerformIO在系统中,构建系统的人可以在非常有效的硬件上创建纯粹的功能抽象.所有真正的语言都有漏洞,使系统构建者能够以比下载到C代码或汇编代码更有效的方式完成工作.
至于副作用和I/O如何通过IOmonad 适应Haskell的更广泛的图景,我认为考虑Haskell最简单的方法是它是一种描述有效计算的纯语言.当描述的计算是main,运行时系统忠实地执行这些效果.
unsafePerformIO是一种以不安全的方式获得效果的方法; 其中"不安全"的意思是"必须由程序员保证安全" - 编译器不会检查任何内容.如果您是一名精明的程序员并且愿意履行重大证明义务,您可以使用unsafePerformIO.但那时你不再在Haskell中编程了; 你是用一种看起来很像Haskell的不安全语言编程的.
- @Stefan:对于这样的问题,"Haskell"表示*Haskell 2010*标准,或者可能是2003年由剑桥大学出版社出版的*Haskell 98*标准.在其他情况下,许多程序员使用"Haskell"一词来描述无论GHC在那个星期实施了什么. (9认同)
- @StefanSchmidt:已经在语言标准中定义的东西.仅仅因为某些东西是ghc的一部分,它不再是haskell的一部分,而是gcc中的任何东西都是C语言的一部分. (3认同)