用Haskell进行系统编程？

Question

在像Haskell这样的函数式语言中，有可能达到非常低的级别吗？(例如创建内核或设备驱动程序)。功能特性(像monad)在那里会快速有效吗？

Answer 1

Haskell本身并没有做任何事情来启用系统级编码。通过外部函数接口(FFI)，您可以调用C/汇编例程，但在这里，您实际上只是将问题外包给另一种语言。

核心挑战-- FFI的使用是这方面的先兆--在于确保您支持(而不是阻碍)运行时。由于自动内存管理和惰性代码管理，Haskell运行时(必然)非常复杂。

中断处理是典型的内核/Haskell问题。如果在Haskell代码深入运行时系统中出现中断，您将无法及时处理该中断。在许多架构上，如果在处理之前有太多中断排队，硬件将出现故障并暂停或重新启动。这个问题似乎是在内核级别使用Haskell的核心症结所在。

monads编辑：进一步思考，monads在系统级代码中可以是一个非常有用的习惯用法。想一想IO在常规Haskell代码中的使用方式:它是一种类型级污染物，会感染执行IO操作的函数。

由于系统编程都是关于资源管理的，因此需要跟踪哪些代码与哪些资源交互。可以想象每个资源都有一个monad转换器，将特定于资源的函数抽象到一个类型类中。例如，我们可能有

class Monad m => MonadNetwork m where ...
class Monad m => MonadDiskDrive m where ...

需要同时使用网络和磁盘驱动器的代码将带有如下约束

downloadToFile :: (MonadNetwork m, MonadDiskDrive m) => URL -> FilePath -> m ()

这显然是一个高级示例(人们不会期望在内核中找到这一点)，但我认为它说明了这个想法。如果你不介意打破传统，拥有一个(倒抽一口气)非C语言的API，那么这无疑是一种将你的操作系统API暴露给用户的合理方式。

这样的API肯定会让我在运行来自不受信任的来源的代码时感到更安全，因为类型然后记录(以细粒度)代码打算做的IO-ish的事情。

所以，是的，我相信monad在系统级编程中是有用的，不是因为效率的原因，而是因为当你运行不在沙箱中的代码时，你想知道代码的意图。

Answer 2

这有可能吗？是的，在Haskell中已经有了操作系统(参见House，LightHouse，hOp，an L4 kernel，还有一个由NICTA在开发L4.verify时构建的第二个L4内核)以及低级操作系统组件(例如：HALVM)。此外，您还可以编写Linux modules。

在这里是有效的吗？Monad是程序员的惯用法。它们不是汇编代码的一些特殊属性，所以我不太清楚你在问什么。关于Haskell，我特别想说的是，关于算法空间使用的推理困难是Linux模块工作中的主要障碍，这部分是由于GC，部分是由于懒惰。由于无法通知GHC当前的执行上下文(对于kmalloc标志)，这个问题稍微恶化了一点，但这实际上是一个可以清理的细节，目前可以被悲观的假设所掩盖(到处都是GFP_KERNEL)。您可以从内核模块的工作中查看my slides，但要知道，它们是为了促使我(演示者)在某些问题上发言，而不是孤立的。

Answer 3

已经有许多用Haskell编写的低级软件。请参阅http://www.haskell.org/haskellwiki/Applications_and_libraries/Operating_system

monad本身并不是高效或低效的--它取决于您使用的是哪一个特定的monad，以及您使用它的方式。您想要询问的是高阶函数(顺便说一下，这就是制作monad所需的全部)。如今，HOFs的许多用法都可以编译成高效的低级代码。