Systems programming in haskell?

Question

Hey guys,

Ive been thinking...Is it possible to go very low level in functional languages like haskell?(like making a kernel or device driver).And will functional features (like monads) be fast and efficient there?

Thanks in advance

Answer 1

There have been numerous low-level pieces of software written in Haskell. See http://www.haskell.org/haskellwiki/Applications_and_libraries/Operating_system

Monads are not inherently efficient or inefficient -- it depends on which particular monad you are using and how you are using it. What you want to ask about is higher order functions (which, by the way, is all you need to make a monad). These days, many uses of HOFs can be compiled to efficient low-level code.

Answer 2

Haskell itself doesn't do anything to enable systems-level coding. Through the foreign function interface (FFI) you can make calls into C/assembly routines, but here you're really just outsourcing the problem to another language.

The central challenge -- and the use of the FFI is a harbinger of this -- is in making sure that you are supporting (and not hindering) the runtime. The Haskell runtime is (by necessity) very complex, owing to both automatic memory management and the management of lazy code.

Interrupt handling is classic kernel/Haskell problem. If an interrupt comes in when your Haskell code is deep in the runtime system, you won't be able to handle the interrupt in a timely manner. On many architectures, if too many interrupts queue up before being handled, the hardware will fault and either halt or reboot. This issue seems to be the central crux in using Haskell at the kernel level.

Edit: On further reflection, monads can be a very useful idiom in systems level code. Think about the way in which IO is used in regular Haskell code: it is a type-level contaminant that infects functions which, well, do IO-things.

Since systems programming is all about resource management, it is desirable to track which code interacts with which resources. One could imagine a monad transformer for each resource in question, with resource-specific functions abstracted in a type class. For instance, we might have

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

Code which needs to use both the network and disk drive would carry constraints like

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

This is clearly a high-level example (one wouldn't expect to find this in a kernel), but I think it illustrates the idea. It certainly would be a reasonable way to expose your OS API to user-land, if you didn't mind breaking tradition and having a (gasp) non-C API.

Such an API would definitely make me feel safer about running code from untrusted sources, as the types then document (with fine granularity) what sorts of IO-ish things the code intends to do.

So yes, I believe that monads are useful in systems level programming, not for efficiency reasons, but simply because when you are running code which isn't in a sandbox, you want to know the code's intentions.

Answer 3

Is it possible? Yes There have been operating systems in Haskell (see House, LightHouse, hOp, an L4 kernel, and there's a second L4 kernel built by NICTA when developing L4.verified) as well as low level OS components (ex: HALVM). Also, you can write Linux modules.

Are Monads Efficient Here? Monads are a programmer idiom. They aren't some special property of the assembly code, so I'm rather unclear of what you're asking. With respect to Haskell specifically I'd say the difficulty of reasoning about the space use of the algorithm is the main blockade in the Linux module work, this is partly due to the GC and partly due to laziness. The problem is slightly exasperated by an inability to inform the GHC RTS of the current execution context (for kmalloc flags), but that's really a polish detail that can be cleaned up and currently covered up by pessimistic assumptions (GFP_KERNEL everywhere). You can review my slides from the Kernel module effort, but know they were made to prompt me (the presenter) to talk on certain points and aren't made to stand alone.