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.