Criticism ... synthesis? .. criticism..

Dr. J. Van Sckalkwyk (external) SCHALKW@odie.ee.wits.ac.za
Sun, 18 Dec 1994 05:40:24 SAT


Hi all!

>   I'm new to here 
(Welcome).


> 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, 
[...]

Thanks for highlighting this. I really do not believe that it is 
possible to be all things to all people. My objective would be much 
more "limited" - i.e. to define an "OS" that is as powerful and 
general as I can make it, with a higher layer "language" that 
provides ease of use. My interest in the other 50 million programming 
languages would be secondary and subsidiary - although I do believe 
that smart programs written in a coherent HLL might be able to adapt 
great big chunks of eg C or PASCAL for their own use, for example!



> 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.

The reason why _I_ve been forced down to a lower and lower level is 
simply that, although several languages (eg LISP) have very desirable 
features, and have indeed tickled my fancy, NONE has come up to 
scratch when it comes to getting down and doing some really serious 
work (especially as the OS is quietly fucking you underneath, all the 
time).



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


Absolutely. But let's outlaw arbitrary constructs (eg. a particular 
way of implementing a matrix, a linked list, or whatever)! KISS.


>   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).

My _ideal_ is a LLL that contains only necessary primitives (however 
you represent them). There will be deeper (transparent) machine 
dependent code on each & every machine, but the concise, powerful LLL 
unifies all. Above the LLL you can have a hierarchy (or whatever) of 
more abstract constructs. 
This would be clean, keen and mean! Most users operating on a higher 
abstract level would never see it.


>   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.

Yep. As I said, my goal is much less ambitious.
((Parenthetically, tho, if your primitives are really simple and 
_sufficient_ then there should be no reason why you should not write 
a C compiler, a Pascal compiler, or whatever in our LLL (let's call 
it "J"). You might have a biiig problem on a Lisp machine, or 
whatever))!!



> 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
>

No flames, but many thanks!
_My_ concept is more or less by analogy with biological systems:
Consider the hierarchy:

DNA -> control of cellular subsystems -> cell ....---> organism.

Can we not have efficient core code (DNA has 4 different bases 
grouped in triplets) that is simple; fairly complex intermediate 
levels; and then a fairly well-defined, useful building block (the 
cell) that encapsulates a lot of hidden processing power, but is 
nevertheless small enough to be useful? Mike & I would be somewhere 
around the "J" / "DNA" level, Fare, I think, at the "Joy" / "cellular 
level".

Synthesis, rather than antagonism!

What does everyone think?


JVS.