From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA24477; Wed, 21 Nov 2001 22:25:57 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA24812 for ; Wed, 21 Nov 2001 22:25:56 +0100 (MET) Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fALLPen03536 for ; Wed, 21 Nov 2001 22:25:45 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Caml-list] Rewriting UNIX in Caml and getting rid of the C disease Date: Wed, 21 Nov 2001 16:25:12 -0500 Message-ID: <706871B20764CD449DB0E8E3D81C4D4301FA2278@opus.cs.cornell.edu> Thread-Topic: [Caml-list] Rewriting UNIX in Caml and getting rid of the C disease Thread-Index: AcFqcfqYzsjINo/xQ+6p90b+kGLDRgIX+E6g From: "Michael Hicks" To: "Berke Durak" , Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Just to resurrect this thread: Many of your observations on the inadequacies of C (and those of the people who followed up) are addressed in a language being developed at Cornell and AT&T Research called Cyclone. It incorporates successful high-level language features to ensure safety, but unlike most high-level languages, gives the programmer control over data representation and, to a large extent, memory management (e.g. a GC is not required). Furthermore, Cyclone is very close to C, thus simplifying the process of porting legacy code (we actually parse a superset of C, but our type-checker is more restrictive, as you would imagine). In essence, the language was designed with just your sort of systems project in mind. So far we have written a 40,000 line compiler in Cyclone, and ported nearly 30,000 lines of systems code. So that I'm not too off-topic, I should say that OCaml has been a strong influence on Cyclone---many of the OCaml libraries and tools were ported to Cyclone, and many of OCaml's features have been added to allow more high-level programming, if desired, including exceptions, pattern matching, tagged unions (i.e. datatypes), and others. Of course, "OCaml-like" is not OCaml itself; OCaml should be the language of choice for applications where low-level control is not as important (of which there are many). http://www.cs.cornell.edu/projects/cyclone/ has more details. There is much more to be done, and comments are welcomed. Mike > -----Original Message----- > From: Berke Durak [mailto:berke@altern.org] > Sent: Sunday, November 11, 2001 12:18 AM > To: caml-list@inria.fr > Subject: [Caml-list] Rewriting UNIX in Caml and getting rid of the C > disease >=20 >=20 > Everyone on this list will agree that the C language is far from being > perfect. More specifically, if we consider its various derivatives > together (i.e. the C preprocessor and C++) they form the worst piece > of stinking, pathogen and toxic garbage in the realm of programming > languages. >=20 > On the other hand, we almost all use and respect UNIX and its > derivatives, which might seem to be a paradox, given that UNIX is > entirely based on C. I'm here considering UNIX from the system > programmer's view, making abstraction of the way it's > implemented. Certainly, it could get much better, but, practically, it > is just fine. >=20 > Unfortunately, the C language acts as a mandatory layer over > UNIX. Generating an executable for a given brand of UNIX without going > thru the C library is tricky because it requires to know how the > system calls work. These are, first, not documented (because you're > supposed to go thru the C library), and, second, depend precisely on > #ifdef-infested C source code, and are subject to revision. >=20 > Therefore, in the interests of humanity, I hereby propose that : >=20 > *** >=20 > An appropriate sublanguage of Caml should be isolated, and a given, > well-accepted brand of UNIX should be reimplemented in that language. > Binary compatibility must be retained as far as possible. Basic system > utilities (including a shell) should also be translated (into full > Ocaml). Since the use of Caml will, a) divide the source code size by, > say, ten and b) automatically remove, say, 95% of all bugs and > security holes (since most are illnesses resulting from pointer > manipulation), success is guaranteed. >=20 > *** >=20 > Progress has to be made in operating systems. C blocks that progress. > C must be obliterated. >=20 > The use and existence of a Caml-based UNIX, with a (justified) > reputation of very good security and integrity, will invariably > attract a lot of hackers (in the good sense) to Caml. It will also > make existing Caml programmers a valuable resource. >=20 > The use of Caml might also facilitate the verification of some parts > of it using Coq, even if I don't know what part of an operating system > you could usefully verify by formal methods. >=20 > For marketing purposes, a bijective mapping between some sort of > subgrammar of C and the sublanguage of Caml could be provided. >=20 > For people worrying about speed, I'd just remind them that not so long > ago, C itself was considered pretty slow and inefficient a language > (maybe the compilers weren't as good), yet operating systems=20 > were written in C and used on computers a thousand times slower than > what we have today. >=20 > Finally, the task of translating UNIX from C to Caml, if certainly > not straightforward, is certainly feasible with a predictable amount > of work, and could even be made semi-automatically. > -- > Berke > ------------------- > Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:=20 http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr