Criticism ... synthesis?

[Juliusz Chroboczek]

  Hi!

  I'm new to here (I crossed Fare in a lobby last week and had to sign
on :-) ), and feel I need a summary of your conclusions.  So here is
what I do and what I don't understand.

0. We are sketching the OS of the future.

1. We want to define a set of data structures *in* the system.
  
  Yet, we all know that data structures *do* fix the HLL we use, and
although I have nothing against Lisp, Forth, SmallTalk, Dylan, SML,
Caml, Scheme, C, C++, C+@, Pascal, Concurrent Pascal, Rascal, Mumps,
APL, <insert your favorite one here>, I would strongly resent anyone
trying to force me to use one of these.  I want the freedom to use the
best language available for my task, and would strongly resent the OS
I use to limit me.


2. We want to define a standard Low Level Language.  This would allow
us to be portable between systems: let's outlaw machine code!

  But, by saying LLL, you seem to mix up a few concepts.  Apparently,
this language would be a portable bytecode as well as the intermediary
representation for all our compilers, as well as the LLL used by
humans on our machines (sorta C).
  Well, designing such a language is quite difficult.  A common
bytecode for compilers is impossible: for instance, you might want to
access a variable in one bytecode instruction, and since languages
have different scoping rules, this precludes the use of a common
bytecode for different languages.
  Many people have tried to design a common intermediary language for
compilers, the most recent such project being the GCC compiler.  In my
opinion, all have failed (for the project is way too ambitious) (the
Dragon Book, if my memory serves me well, describes a few such projects).
  Furthermore, if we are to define a common LLL, we must reduce the
scope of our ambitions, for instance to Von Neumann machines with a
few conditions about memory addressing.  Just try to design a language
that is low level enough (therefore close to the hardware), on modern
RISC machines (Von Neumann machines with linear addressing, simple
instruction sets, and complex efficiency considerations), Lisp
machines (Von Neumann machines with a bizarre memory layout and very
curious memory considerations), and experimental Rewrite machines
(synchronous networks with fine grained parallelism -- not VN at
all!).


3. We want to agree on the architecture.

  Technically easy (I have very definite opinions on this one, but
this is not the time to speak them aloud), but politically impossible.
  The simplest thing to do would be to resort to Software Communism:
all code is made equal, no class privileges, and therefore no
security.  Technically sexy, but pragmatically unacceptable.
  Another point of view (Fare's), Software Democracy, consists in
distributing privileged code accross the system.  This stems naturally
from Fare's hatred of centralism, and might be doable (I was convinced
of the opposite until I had a longish conversation with Fare last
night).  However, this would mean having privileged code floating
everywhere, which is clearly not what we want.
  The third point of view, Software Monarchy, consists in having a
small amount of privileged code (call it a Kernel), and the rest of
the system calling the kernel each time it needs to do a privileged
operation.  This point of view is not very original, and has already
been implemented, in particular in CMU's Mach.



  Please do not flame me, but I'd be very surprised if you managed to
have anything done.
                                   J. Chroboczek