icsu8209@khan.cs.montana.edu (Glassy) (07/11/90)
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? Please e-mail your pensees, or post as you see fit ;) Thanks Lou Glassy icsu8209@caesar.cs.montana.edu
murthy@algron.cs.cornell.edu (Chet Murthy) (07/11/90)
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? The Pegasus people probably have a lot to say about this - they have implemented an entire operating system in a variant of ML. Now, of course, this ML was quite imperative; nevertheless, they were able to make good use of the polymorphism and higher-order features of ML. -- A woman who lets men pay her way (unless she simply acquiesces to their insistences over her stated wishes) is like a man who hangs around beautiful big-breasted women and marries for love. --chet the hardliner-- murthy@cs.cornell.edu
kato@is.s.u-tokyo.ac.jp (KATO Kazuhiko) (07/14/90)
In article <43178@cornell.UUCP> murthy@algron.cs.cornell.edu (Chet Murthy) writes: |Path: is.s.u-tokyo!s.u-tokyo!ccut!sun-barr!decwrl!ucbvax!ucsd!usc!wuarchive!mailrus!cornell!murthy |From: murthy@algron.cs.cornell.edu (Chet Murthy) |Newsgroups: comp.lang.functional |Date: 11 Jul 90 14:25:18 GMT |References: <2189@dali> |Sender: nobody@cornell.UUCP |Organization: Cornell Univ. CS Dept. Ithaca NY |Lines: 22 | |The Pegasus people probably have a lot to say about this - they have |implemented an entire operating system in a variant of ML. Now, of |course, this ML was quite imperative; nevertheless, they were able to |make good use of the polymorphism and higher-order features of ML. Have any papers of Pegasus been published? If so, would you tell me them? -- Kazuhiko KATO E-mail: kato@is.s.u-tokyo.ac.jp Postal: Dept of Info Sci, Fac of Sci, Univ of Tokyo 7-3-1 Hongo, Bunkyo-Ku Tokyo, 113 JAPAN Tel: +81 3-812-2111 ex.4104 or 4095 Fax: +81 3-818-1073
tom@stl.stc.co.uk (Tom Thomson) (07/16/90)
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
kers@hplb.hpl.hp.com (Chris Dollin) (07/18/90)
Tom Thomson says (among other things):
(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 ).
A language need not have a compile-time type system to be functional. Indeed,
early languages like SASL and KRC (and EL Ziro, which is the language I
implemented for my thesis lo! those many years ago) were dynamically typed.
I've gone off strict compile-time type-checking since I started using
dynamically-typed languages. See how easy it is to get corrupted?
--
Regards, Kers. | "You're better off not dreaming of the things to come;
Caravan: | Dreams are always ending far too soon."kh@cs.glasgow.ac.uk (Kevin Hammond) (07/19/90)
In article <3209@stl.stc.co.uk> "Tom Thomson" <tom@stl.stc.co.uk> writes: >(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 ). What exactly did you have in mind: we have considered extensions to the Haskell type system but these are very much experimental (usually it's the type theory that's an issue). Are you in favour of full-blown dynamic type-checking? With/without type-inference? What do you require that OO type-systems give you, but FP systems don't? >(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. We've taken LML (and some Haskell) programs and run them directly on GRIP. The same compiler is used for both Suns and GRIP (with some extra support for the parallel system) so all the tricks used to get fast sequential systems are picked up for free. Currently we're placing sparks by hand (we need information on what the best placements are before we can do this automatically), but we hope to devise good automatic annotation schemes. For the right programs, we already get good speedups (linear speedup compared with a Sun3), but there is still a lot of work to be done to generalise our results. Simon can probably comment further. Kevin -- This Signature Intentionally Left Blank. E-mail: kh@cs.glasgow.ac.uk