Re: [Caml-list] Rewriting UNIX in Caml and getting rid of the C disease

[Arturo Borquez <aborquez@altavista.com>]

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