HLL is not against LLL

[Francois-Rene Rideau]

>>    If we agree to say the LLL is implementation dependent, and consider the
>> one initial implementation we're proposing, it makes sense to specify it,
>> doesn't it ?
> 
> Yes. But it has to be useful. I think we should discuss what is the LLL
> (what features it has and doesn't have) and why we need it.
   Well, I thought this was something long agreed from before TUNES was
named TUNES ! But you're right: if things are not clear, they should be
settled quite clearly.

   So here are some assumptions:
* we want our OS to be and distributed over heterogeneous networks.
* we want it to be standalone and dynamically extensible.
* we want to have a implementation as quickly as possible.
* we want it to be as efficient as possible in the above limits
   Do anyone disagree ?

   Now,
* because we want to be standalone, we must be able to generate new code
 on the fly, be it compiled or interpreted, or a mix between the two.
* because we want the implementation to be efficient, we must be *able*
 to compile code to the lowest possible level.
* because we want to run quickly on multiple platforms, we must write some
 generic, portable code.
* Thus, we must have some portable low-level code somewhere, which is written
 in low-level languages.
* Hence we need have some low-level language(s).

   So what are these LLLs, how much are they used, by whom, etc ?
* standard encodings for efficient communication: encode objects so that
 they take as little volume/speed resources as possible during transfer,
 while still allowing efficient manipulation of the objects afterwards,
 and having complete interoperability for 
 This I have diagnosed as being relevant to the Migration subproject rather
 than the LLL subproject.
* internal code representation meant for fast execution of dynamically
 generated code, yet as portable an implementation as possible. This is
 the LLL proper. It can include lots of implementation dependencies, as
 long as it provides ways to encode and decode it in formats that suit
 migration better.

   In the case of migration, this is rather an encoding format, and should
be extensible so as to suit the needs for the semantics of the objects to
be migrated. Thus, this is rather a set of low-level representation for
low to very high level languages than anything else.
   In the case of the LLL proper, the mechanism for self-extension should
be straightforward and time-efficient. As a *simple* *portable* implementation,
I suggest to begin with a threaded implementation of a stack language, which
offers reasonable speed on all processors; implementation dependencies are
cell size, macros to access data, etc. Actually, the whole system can be
done by expanding macros (see the stuff in the pre-release of 0.0.0.20).
   Then, I'd prefer the HLL to be defined asap, so the "macros" can be
converted into valid HLL (meta)-programs.