LLL & HLL & OS, definitions & implementations

[Nathan Hawkins]

On Thu, 11 Apr 1996, Eric W. Biederman wrote:
> 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.

I would say that your statement about the LLL being harder to work in 
than the HLL is programmer-dependant. I would find the reverse to be true.
That's why I want to be playing with the LLL, instead. Let's say rather, 
that as long as the two are allowed to coexist, and as long as the LLL shall
be defined to support loading of modules/libraries, if someone wanted to 
write portable LLL code, it should be possible. Let's not rule that out. 
Just make that a low priority relative to the main effort. Ok?

One reason for this, is that this allows multiple HL projects to be 
launched over the LLL, promoting code re-use of a (hopefully) efficient 
system core. Somewhat like Mach has been the base for many decent 
projects, let the LLL project be open to all projects that can use it. 
This makes sense, given that we're using the GPL.

> 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.

Possibly it should be said that it is undecided. Major portions of it 
should be portable, I would assume, needing only the lower end 
(meta-compiler) to be system dependent. Hence, I would expect it to be 
mainly a defined piece of code, at some point in time. But that's up to 
other people.

> 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.

That would be nice. Personally, I'd like to see the LLL built in such a 
way that it can contain modules, optional or mandatory, whatever, but 
providing features for those who want them. So we could have assemblers 
written in LLL, which the HLL could connect into, and compile their own 
code, or on systems without one, but with LLL, the HLL could compile to 
that, or compile it's own binaries. Bytecodes I'm not so keen on. I'd 
rather have threading. (Niggling detail. :-)

But this is going to be best accomplished by providing a component/module 
system within the LLL. (We can assume the HLL can do it.) Granting this, 
and that the modules can be dynamically loaded and removed, (which most LL
languages can't do) we allow the LLL to be used for whatever the user 
wants. If that user is the HLL, fine, it can do anything. If the user is 
some LL hacker, like me, he can have a LLL debugger, if he wants. Or 
whatever.

That's why we want a reflective language like Forth, but not Forth 
itself. So we can all do what we want, the way we want, rather than be 
bound by the static design of the language/environment, like with C.

> 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.

Better yet, when I find out enough about GC, I'll begin coding on that, 
and we'll start to get the LLL project _really_ going. Until then, I've 
got a chunk of code that I'm about to release, as soon as I convert it 
over to as86. (I'd been using gas.) This code is just a minimum set of 
Forth operators, no compiler. Just the arithmatic, logic, and stack 
operators, and a frame to hang more code on. Hand compiled Forth... :(

Would anyone who is/was/would-like-to work(ing) on the LLL-i386 project 
please contact me? I've only talked to Fare, and I'd like to know who else
is seriously interested in coding, instead of discussing it to death.
To me, the point of the present discussion, has been to find out what 
the HLL requires of the LLL, and whether that can be compatible with my own
wishes for the LLL. (Which I want for my own dark LL purposes...)

As for how the HLL works, besides it's LL interactions, I don't really care.
  :-)

*utsl*