First I must retract what I wrote, ie,
GHC code can interface with C code, but not as efficiently or as flexibly as C or C++ code can interface with C code.
--to which Alastair replied:
the foreign function interfaces have been getting pretty damn good and, if you know your tools 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.
I was just kind of guessing and surmising, so Alastair's evaluation of FFI is probably the correct one. Alastair:
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.
To kind of summarize, I would like people to voice agreement or disagreement with these next few points. (I'm anticipating wide agreement with all of them.) One of Haskell's strongest points is that more than almost any other PL it allows the programmer to avoid paying attention to the details of memory and cpu usage when memory and cpu usage are unimportant. (But sometimes it is important, so...) For a programmer to learn to control memory and cpu use *well* in Haskell is a very big job --bigger than, eg, learning monads (a *big* stumbling block for the industrial programmers than blow through here and the FP newsgroup) or existential types. So let me talk concretely about that a little, just so people have some words and images to hang their thoughts off of. The way I program in Haskell, I do not concern myself with resource control till I run my program and get empirical evidence that it's too strict (stack overflow or infinite loop) or too lazy, then I ask myself how I can add a ~ to make it lazier or add a seq or rewrite, eg, foo::[(Foo,Bar)]->Baz foo xs = bar xs with foo ((x1,x2):xs) = bar ((x1,x2):xs) (which the mathematician in me wants to consider equivalent in all ways, but sometimes they lead to different resource usage patterns) to make it stricter. Resource control in Haskell is a murky business to me. monads and existential types are the kind of thing I enjoy learning and working with --while not exactly easily and quickly learned, they're "tight" and "mathematical"-- but controlling cpu cycles and memory in Haskell does not have that tight, mathematical flavor I like. Finally, are we all in agreement that it would be a great thing if someone invented a Haskell-like language as good as Haskell at hiding resource usage when resource usage is unimportant, but that made it easier to control resource usage than Haskell does when resource usage is important?