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 WAA13787; Mon, 12 Nov 2001 22:52:43 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA13477 for ; Mon, 12 Nov 2001 22:52:42 +0100 (MET) Received: from c012.sfo.cp.net (c012-h013.c012.sfo.cp.net [209.228.13.213]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id fACLqfH09013 for ; Mon, 12 Nov 2001 22:52:42 +0100 (MET) Received: (cpmta 27704 invoked from network); 12 Nov 2001 13:52:40 -0800 Date: 12 Nov 2001 13:52:40 -0800 Message-ID: <20011112215240.27703.cpmta@c012.sfo.cp.net> X-Sent: 12 Nov 2001 21:52:40 GMT Received: from [24.152.103.148] by mail.altavista.com with HTTP; 12 Nov 2001 13:52:39 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: berke@altern.org From: Arturo Borquez Cc: caml-list@inria.fr X-Mailer: Web Mail 3.9.3.5 Subject: Re: [Caml-list] Rewriting UNIX in Caml and getting rid of the C disease X-Sent-From: aborquez@altavista.com Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 10 November 2001, Berke Durak wrote: > > 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. > > 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. > I agree with you that C/C++ are the most pathological and toxic programming languages ever made, but at UNIX OS kernel level they do quite well (because the huge amount of manpower invested in debugging by miriads of programmers and testers thru last 10 years). and are fairly stable and reliable. I am not sure that the effort porting actual C based kernel would be 'payed' to achieve substantial results. What is really wrong is using C in high level apps. I think that is better to build a parallel version of Caml libraries to interact directly with the kernel thru a Caml System Abstraction Layer (CSAL), bypassing intermediate messy, fragmented, specifical to C limitations libraries. Then at a second stage when CSAL implemented and working, perhaps it will be the time to replace the whole C kernel. The benefits of this aproach are: 1)legacy UNIX software will work seamlessy with the traditional lib's support, or it would be necessary to provide API compatibility to it. 2)CSAL will be designed to take full advantage of Caml language (or not necessary to built it arround actual lib design?). Full multithreading and dynamic linking should be provided to work properly with CSAL, an some GC adaptations?. 3)Legacy Caml apps will also work seamlessy as pointed in 1) with traditional libs. Moreover it will allow to do 'mixed' apps. 4)GC timing overhead will be mitigated thru a more 'direct' acces to system resources (More than 90%+ of time programs are excuting inside lib's code) shortening the path to 'active code' and reducing the number of calls needed to complete a usefull action. 5) It seems me this strategy is not as radical as you propose and don't put aside the idea of a 'total' replacement, but doing it in two steps so with limited Caml manpower would be more doable?. It also allow an 'incremental' developemt of CSAL with Caml, deprecating old environment gradually as CSAL evolves. My proposal is a 3 layer model, native-unix-kernel->CSAL->Caml apps. to reach the final model, caml-unix-kernel->CSAL->Caml apps. Another important issue is that this SAL should be be compliant with POSIXS or not?, or if we should have full freedom to define it at the best to fit with Caml features and more 'modern' design?. My opinion favours the later, in spite it would take an aditional step defining what's the 'modern' design is. The pricipal drawback of this proposal is this CSAL will be CAML propietary, as no third party languages API's will be provided, nor it will intedended to do. It will need maintaining support as UNIX kernel's evolves. This fact will also constrain CSAL to kernel limitations. I think that a project like this would need the aproval, support and commitment of INRIA, and I don't know if this idea is barely considered in their plans, prorities? (it seems me not). Undoubtly OS design and languages, have a great importance and makes a big difference (productive time /(productive time + wasted time)), on all stuffs derived from them. It is unbeliable the ignorance and misunderstanding I've found among industry IT's and 'engineers' who are still using CRAPS. Best Regards Arturo Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com ------------------- 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