Some comments on HLL/LLL from the peanut gallery

[spc@gate.net]

  I've read the Tunes web pages, and I've seen some of the discussion about
what should be in the HLL and what should be in the LLL and how do we
impliment this, that and the other.  

  What's the point?

  And please, don't take this the wrong way.

  What I mean is, why does the language matter?  All this focus on one
language (well, two, the HLL and LLL) is promoting the myth (that Unix may
have started) that a "portable OS" (and that is what you are designing,
whether it has a kernel or not) has to be written in one (or in your case,
two) language(s).

  Yes, Unix is written in C, but there isn't anything keeping it from being
written in something else, say, a souped up Pascal.  Who would know the
difference if you could still write code in C?  In Unix, really, the only
important thing is the API.  As long as there was a consistant method to
call the OS that both sides (the usermode program and the OS), who cares
what the OS, or the app, is written in?

  A good example of what I'm talking about is AmigaDOS.  Exec (arguably the
"kernel" of the system) in Assembly (at least on the 68K based ones - I'm
sure Escom is rewriting this in some higher level language for their rumored
RISC based Amiga, but I digress), DOS (which handles the filesystems and
impliments the concept of a "process") in BCPL (initially, again, I'm sure
rewrites have been done in C) and Intuition (the GUI) in C.

  So, here's an OS written (or at least initially) in three different
langauges, and as far as the apps go, it doesn't matter.  The method used to
call the OS (actually, shared libraries, since Exec, DOS and Intuition are
implimented as normal shared libraries) is well defined and followed by all
the subsystems (and shared libraries) [1].  

  Now, because of this, one is not forced to write system extentions (or
shared libraries, or device drivers (as they're a subclass of shared
libraries) in one language.  Theoretically, I could write a shared library
in ANS Forth, and with the right declarations (or header files, or module
definitions, or some other magic), someone using Scheme can use my library. 
All I do is give them the API my shared library offers, and off they go.

  I realize that one of the goals of the HLL is a very safe and provable (I
still think this is unobtainable, but that's me) language so that it is
impossible to crash the system, but on the other hand, you don't want to
force people into only one way of computing either (if I understand you
correctly).

  So, an object can be written in any language available, and as long as it
follows the standard calling convention (or the calling convention can be
discribed so that other objects can call it) it doesn't matter what it was
written in.

  Granted, you might be concerned about safety and provability, but just
make the language it was written in part of the object (even a text string
such as "PandaStar Haskell 1.7" or "MickySoft C++++--= 2.1" or "Fare' HLL
1.00").  If you don't trust MickySoft C++++--=, then the object isn't
allowed to run.  

  Unix proved (beyond any doubt) that an OS can be ported to just about any
hardware in existance.  But all those implimentations were done in C,
because it was first done in C [2].  But I contend that an OS can be done in
any language (even several at the same time), it doesn't matter.

  Besides, we've yet to come up with a language that is all things to all
programmers.

  -spc (Just my two peanuts from the peanut gallery)

[1]	Okay, so there is some inconsistancy in register usage, but the
	only time this is of any concern is when one is writing in Assembly.
	Most Amiga compilers (pick your lanaguage) can, and do hide this
	inconsistancy from you.

[2]	Not really.  It was first done in Assembly on a PDP-7.  It was only
	later, after C [3] was developed, was it recoded in a more portable
	fasion.

[3]	C was derived from BCPL, which in turn was derived from CBCPL.