Some comments on HLL/LLL from the peanut gallery

[spc@gate.net]

On some network somewhere in cyberspace, Patrick Premont transmitted:
> 
> 
> >   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).
> 
> Tunes is not just an OS. It is also a language, the HLL. So we have to
> worry about what this language will be. Then we want the system to
> be bootstraped so it has to be writen in itself. But of course we
> have to start from some other language to solve the cyclical dependency
> problem. We need something that we will be able to evolve into
> our HLL so we have to worry about that language too.
> 
  So, Tunes is more like the system software found on the old 8 bit Atari's,
Commodore 64s and Apple ][s in that the language (BASIC in this case) is the
OS.  Or the Xerox Star with Smalltalk.  And many Forth based systems are
like this as well.  

  Well, I don't see systems around like that anymore, maybe because they're
not practical, but on the other hand, it might be that it might be time for
such systems to make a come back.  

  But I would suggest you drop any notions of being able to evolve any code 
you write the HLL in into HLL.  Write it once in <pick your language>.  Once
you get the HLL going, start over from scratch, writing the HLL in the HLL. 
You'll end up with something that is cleaner.
  
> And finally there is a low level structure upon which we must agree
> and that's where the LLL comes in.
> 
  Okay, so at this point I'll apply my same argument:  Who cares what the
LLL is?  As long as the HLL can talk to the LLL, reguardless of what the LLL
is, why bother with defining an LLL?

  Another suggestion, check out Java.  It may not meet the requirements for
the HLL, but as far as the LLL goes, it's already a bytecode system where
Java binaries can run, unmodified, on multiple systems.

> Only the HLL will be available to users/programs at first. We intend
> to make it so well intergrated into the OS and so great that no one
> will want to use other languages. 

  So I can hack the hardware in the HLL, while at the same time, compute e
to 1,000,000 digits, AND write a natural language parser?  I'm sorry, but I
still don't buy the "All singing, all dancing" language.  We have a few of
those, the most notable being Ada, another C++.  There's a reason why
certain languages evolve (or are written):  to precisely solve a problem in
a particular domain.  Fortran for numerical analysis.  C for systems work. 
Lisp for AI.  

  Besides, what happens to my rather large base of C code?

  -spc (Languages limit what constructs we can devise ... )