🚀 go-pugleaf

In article <2189@dali> icsu8209@khan.cs.montana.edu (Glassy) writes:
>From my various readings (local resources, + this newsgroup), it
>appears that one of major impacts of functional programming languages
>has been, is, will be, to put the creation of programs on a more
>mathematical (sounder? more provable?) basis.  Do any of the current
>FPL's (scheme, haskell, SML, Miranda, Hope) venture yet into the
>realm of OS implementation?  Are we doomed to suffer with C and its
>progeny ad-in-#define-itum for the implementation of operating system
>software?
Here at ICL Manchester (in conjunction with Manchester University) we have
done quite a lot of work in this area.  We implemented a skeleton 
operating system for a 16 off 68020 share-nothing machine in HOPE+ (with
the addition of a very-much-simplified form of guardians), and got enough
of a database running on it to demonstrate linear speed-up from 1 to 16
processors on the debit-credit benchmark. We are following this work up in
a pan-european consortium, but we've dropped the use of functional language
for implementation and reverted to C (++ maybe) for a number of reasons:-
(i) you have to be able to run other people's software (tools, DBMSs,
   application packages). That means UNIX and interfaces callable from C.
(ii) No functional language has yet managed to incorporate any decent concept
  of IO, or DataBase access, etc (Haskell has made a small step along this 
  line; there's been work at Oxford and Glasgow which may lead somewhere
  but it aint there yet).
(iii) With the exception of ML (Lisp doesn't count: not a functional language)
 the functional languages have been controlled by "purists" (I don't mean to
 claim this is wrong; the science hasn't yet reached the stage where one can
 afford to chuck away the conceptual simplicity provided by the purist
 approach, and the technology is nowhere near) who will not incorporate
 non-declarative/non-deterministic effects into the programming model; but
 operating systems are about interactions with the world, which don't fit
 this model. If your program has to exit returning a continuation to have
 it's side effects, it isn't going to be very good at programming up those
 side effects. (Bottom-avoiding merge is probably enough here, but we 
need fiendishly clever optimisation in the compiler if we go down that track.)
 (iv) A functional style appears to be incompatible with strong 
  encapsulation (at least if you equate "functional" with "pattern matching")
 - - Haskell's fun with abstraction and views is an example; we need to
 work our way around this, it shouldn't be too hard but it hasn't been
 done yet.
  No-one in their right mind is going to try to implement an OS in a 
 language which doesn't permit (that's permit, not enforce) strong
 encapsulation (ok, so we were a bunch of loonies ..... )
(v) Type systems in functional languages are far too simple-minded; can't
 handle polymorphism unless it's parametric polymorphism with all 
 parameters resolvable at compile time. (If only the functional people,
 the OO people, and the type-theory people would talk to each other; again
Haskell has made a step forwards, but it's a smal one ).
(vi) Performance remains an issue  - - although single-processor versions
 of some Ffunc.lang. compilers now produce decent code, no-one really
knows how to parallelize this stuff effectively (I hope some-one
connected with GRIP will explain why this is no longer true!) and a new
OS will have to fit parallel machines. At least with C you know you're
serial - parallelism is built by designers, not by compilers.

Not sure whether the above ramblings make sense, really, but I'll follow
the usual news convention: post and be damned.  

I guess there are three points: (i) it is already possible to write
substantial operating systems in functional languages, provideing one
hacks the dirty bits somehow; (ii) this is not a commercially viable
approach because functional languages are still research toys, so far as
large scal stuff is concerned; they're ok for specifying bits, though. (iii)
even if the languages were ok, we would be stuck with history.

Tom Thomson