LLL & HLL & OS, definitions & implementations

[Eric W. Biederman]

That's a huge topic but it seems to be what everyone is arguing about,
and taking all of the bandwidth to boot so I thought I'd say what it
looks like to me.

undefined  -- means you can't count on something reliable from system
              to system.
undecided -- means no final decision has been reached.

The LLL is/will be a language you can implement any program you can in
the HLL except it will be much harder.  OTOH the LLL will be much
simpler to implement, and may have extensions for various hardware
architectures etc that will make it good for LLL work.  It's
portability is currently undecided.  How it's implemented is undefined.

The HLL will be an awesome language that you can do anything/everthing
in.  Or a major subset of that.  It will make programming very easy,
or something like that.  It will support persistence, OO, GC, lambda
functions, and a few other language features.  It requires the LLL to
support enough to make the foundations of the HLL not to dificult to
implement.  How the HLL is implemented is undefined.

The OS is a bit of code that really hasn't been defined except it's
OO.  There has been some talk about about how to implement it, single
address space etc.  But implementation details are undefined only
semantics are defined.  That is it will naturally support the HLL &
the LLL.

LLL <= HLL
translation: The LLL ( baring machine specific code) is semantically a subset of
the HLL.

so for a compiler these are legal compilation paths
HLL -> LLL -> asm -> binary  
HLL -> asm -> binary 
HLL -> (small HLL) -> LLL -> bytecode -> asm -> binary 
HLL -> binary 
LLL -> bytecode -> interpreter

etc, etc.  (When we(tunes project people) code it you will know)

>From the current developmental interests there is a fair chance the
LLL will be portable too.  We shall see.


Eric

p.s.  Pleas stop getting lost in little details, Instead of asking
what is this.  Propose that it will work the way you want it too.
Then it's productive.