[newbie]system programming ?

[Alastair David Reid]

Richard  <greon@best.com> writes:

> 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/