Down the design trail...

[Francois-Rene Rideau]

> C is very simple (26 operators), but very 
> extensible (if you can call libraries that).
Well, you can't. Compare C's extensibility to FORTH's or LISP's or even ML's,
and you'll see it ain't. Because C is a first order language; and even the
standard C preprocessor is a very poor first-level language.
C is low-level. C is unextensible. C is unsecure. C is not powerful at all.
C doesn't allow code reuse. C is a static language. C is unamendable.
C sucks. Don't use C. If some people are masochistic enough to ask for it, let
them have it.


> C got from UNIX a bunch of good libraries which made it truly useful,
> along with development tools, etc.
TeX or UNIX being written in C adds nothing to C's usefulness: when you
program in C, the only way to exploit some external program is to fork()
and exec() it (or system() it).


> UNIX loved C's portability, along with relatively easy programming.
C is no more portable than any language; perhaps it is even less portable.
But it is more *ported*, which is quite different ! Unix did not love
C's portability; Unix did create it.


> How does this relate to our project?

> 6.23 Our design should be simple enough to get off the ground
Any design should !

> 6.24 It should allow easy extensions
It should allow easily *powerful* extensions.
This is #1 priority. An OS is the basis for computer work.
It is useful only as it allows any kind of further work to be done
easily, directly inside the system, and in perfect symbiosis with
other work inside the system. If some extension is not possible,
then people will use another system (be it written on top of the
actual OS).


> 6.25 It has to be able to do anything the core CPU can (C's instructions are 
> 	actually pretty low-level)
This is a tricky one, as CPUs evolve rather quick...
And allowing quick and efficient port of programs means such things are done
in conjunction with the compiler...


> 6.26 It has to run fast
Not the #1 priority: this depends heavily on compiler technology; and good
optimizing compilers need time to write (and good assembler code needs even
more time to write). So don't expect the system to run fast until version
34.235.12

> 6.27 It has to be easy to program
This is the #2 priority to me. And remember that *using* is *programming* (and
the other way round).


> 6.28 Easy to port to different architectures
Architectures are not *that* different. Anything you would write for, say,
an i386, would be very easy to port to anything, unless it relied heavily
on segments, which it won't, as segments are so slow and costly, and bring
not much. For a first generic implementation, Let's assume just some 32-bit
linear addressing and pagination. Further implementations for lesser or
greater architectures (8, 16, 20, 64 or 128 bits) will come later.


> What did I forget?  What am I missing the point on?  What am I dead wrong 
> about?
It is very important to acknowledge that our system will be expressed in
some computer language, and that its semantics will thus be limited by that
of this language. Unix semantics suck, because they are expressed in C;
there thus can't be any kind of security or intelligent error recovery under
Unix; there cannot be generic operators, or any second order, or even any
higher order operators under Unix. C is also a static language, with staticly
defined types; there can be no secure system evolution under Unix.
Let us use some higher-order, dynamic language to define our system's
semantics.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
MOOSE project member. OSL developper.                     |   |   /
Dreams about The Universal (Distributed) Database.       --- --- //
Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE   /|\ /|\ //
Phone: 033 1 42026735                                    /|\ /|\ /