Richard
None of the functional programming languages are competitive with procedural languages in programming of traditional kernels. This is because such programming requires finer control over memory and cpu cycles than GHC gives you and because a large part of such programming is designing and using very efficient interfaces to other parts of the operating system.
As a Haskell programmer working in an OS group (University of Utah's Flux group), I've spent quite a bit of time thinking about this and I think this is largely true. Haskell's a great programming language for most programming because it is so good at hiding resource usage from the programmer but since one of the primary goals of an OS is to control resource usage, this is exactly what you don't want when you're programming an OS. ML comes an awful lot closer to being usable. ML doesn't have lazy evaluation so it's relatively straightforward to reason about resource usage: you don't have to think about what thunks have already been evaluated and which evaluation context your code appears in (hmmm, reminds me of the problems faced by the high performance people when reasoning about caches). But, even with ML, we still have to worry about garbage collection. There's a few tricks we can play to avoid problems with interrupt handlers triggering GCs like reserving memory for interrupt handlers to run in or handling interrupts in threads but, still, it's a messy business. I think the most plausible approach is that taken in ML with Regions. There's two interesting things about region-based approaches: 1) They don't require a garbage collector. 2) The type of a function includes information about its memory usage. The current region systems don't provide enough detail in the type to reason about the amount of memory usage but there is enough to be able to reason about when objects get deallocated which is enough to let you apply conventional reasoning techniques. Two variations on the region theme are: o The Vault language from Microsoft research. Doesn't do automatic memory management but provides a type system which (amongst other things) can be used to check memory usage. Usable for writing device drivers. o The Cyclone language recently announced by Cornell (http://www.cs.cornell.edu/projects/cyclone/) This is a typesafe C but, in the talk I saw, Dan Grossman challenged us to find a dirty C programming trick that couldn't be expressed in Cyclone. Oh, and it also includes parametric polymorphism, pattern matching, exceptions and other things we're used to seeing in functional languages.
GHC code can interface with C code, but not as efficiently or as flexibly as C or C++ code can interface with C code.
Of course, this is irrelevant if you write your entire kernel in Haskell :-) More seriously, the foreign function interfaces have been getting pretty damn good and, if you know your tools (and, in my experience, OS hackers know every last flag/extension that their compiler provides) can generate pretty good code. Whilst I don't speak for the GHC team and can only speak for one of the FFI tools, I think you should report is as a bug when you find inefficiency of the FFI to be a bottleneck or that the effort in interfacing to a piece of C code is way out of proportion to the size of the interface. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/