LLL & HLL & OS, definitions & implementations
Eric W. Biederman
Thu, 11 Apr 1996 00:12:43 -0500
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
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 &
LLL <= HLL
translation: The LLL ( baring machine specific code) is semantically a subset of
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.
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.