HLL is not against LLL

[Francois-Rene Rideau]

   We need to clarify things about HLL and LLL.
The goal of TUNES is to provide the design *and implementation* of a
computing system. To me, you may think of the HLL as part of the design,
and LLL as part of the implementation. One needs the other, even though
one is not tied to a particular instance of the other. In a fully bootstrapped
system, one would be written in the other, using language extensibility.
   There is a kind a duality between design and implementation. The LLL could
be used to implement other things that the HLL, and the HLL could be
implemented in other ways than with our LLL. The advantage of the LLL is that
it provides easy portability to the HLL implementation. The advantage of the
HLL is that it provides an high-level way of programming that hopefully
fulfills all of our requirements, among which complete self-extensibility,
which means it can adapt to any situation, and come to be a superset of any
existing language.

Patrick wrote:
>>> I don't think we need to specify a standard LLL for TUNES.

Andrew replied:
>> In the short term, I agree with you.

   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 ?


>> As a long-term goal, however, I
>> disagree.  The issue here is not platform independence, but source
>> language independence.
   Language independence can be done in many ways at many levels. A standard
LLL is a good way to provide both language and platform independence, as
a standard intermediate language. Now, there may be large variations between
the LLL as used to initially bootstrap the HLL, and the LLL as used as some
standard intermediate language; I see the latter as part of the Migration
subproject rather than the LLL subproject itself. Each should feed the other,
but they should be distinct, I think, because their requirements are distinct.


>> I don't think that we're so blinkered as to
>> believe that our HLL will be the only language used under Tunes.  Some
>> problems are better expressed in functional languages, some in object 
>> oriented languages, some in logic languages etc.  We should not oblige 
>> the programmer to use one and only one language to develop applications.
>> We should also design with evolution in mind: We don't know what future
>> programming languages will look like, but Tunes should work with them
>> anyway (though maybe not as efficiently as one would wish).
   Another way to provide language-independence is to do it at a very high
level (see CORBA and ILU): we provide a way to have high-level programs
communicate in a high-level way. As for the TUNES HLL, my goal has always
been to do that through HLL self-extensibility (the HLL can specialize into
any language you want), and meta-translation (provide tools to translate
languages one into another, or both into a common target, so they can
communicate). So the HLL is not limiting and constraining, but freeing.


Patrick answered:
> So you see the LLL as a target language for the HLL compiler and all
> other languages who wish to interact with Tunes. I don't think that's
> a very good move because that means we restrict Tunes "system"
> services (the services which other languages might need) to a low
> level of abstraction (don't we agree that this is bad for Tunes ? We'd
> end up with a LL OS and a HL language just like conventional systems).
   No, TUNES will have no "system services", but will provide a frame
for software modules to specify, define, provide and require services.
Actual services will be provided at whatever level suits better.
High-level services will be available as high-level abstractions, not
low-level implementation (meta-translation allows to use whichever
abstraction suits best).

> I think that the other languages that want to talk to the OS will have
> to do it in the HLL (for exemple you could write a Prolog compiler in
> our HLL, or just extend the HLL to support logic programming). This
> (talking to the OS in the HLL) is to be expected if we want the HLL to
> BE the OS.
   That's precisely how I see it.


I said:
>>    I am still convinced that a LLL is a very good speed-up for the
>> development of a computing system.

Patrick replied:
> To me it looks like a slow down. If you can write your compilers in a
> HLL why would you use a LLL, it just makes it more difficult. Of
> course we need an implementation of that HLL to begin with we'll have
> one if we start from an existing language (we may want to modify that
> implementation a little bit so I suggest we choose one which is free).
   The LLL is just a way to bootstrap the HLL, both as implementation and
target language, much like a FORTH kernels extends into whatever language
you want. What language would you suggest that would allow us to support
the HLL in an interactive environment ?


>> Bytecodes and LISP interpreters are
>> what I call LLLs.
> 
> Surely we don't want to write a compiler in byte-codes. In something
> that can be transladed to bytes-codes maybe but that means the compiler
> is not implemented in the LLL.
   The compiler is implemented in a restriction of the HLL,
which is built as an extension to the LLL.


>> But they are unextensible, unadaptable LLLs. I prefer
>> using some FORTH-like LLL, so it can adapt to the hardware (easy to
>> add words written in assembly) and extend naturally into the HLL, thus
>> yielding much better integration.
> 
> Writing the HLL compiler in a language without an object system makes
> it more difficult to modify.
   Why wouldn't objects be expressed easily in some proper extension to
the LLL ? See object extensions to FORTH (MOPS, OOF).

> Knowing that the compiler can/will be
> made available at run-time, a program might want to recompile itself
> with a modified compiler (to avoid the Pentium floating-point bug for
> example). It will be made mode difficult and "ugly" if that requires
> hacking in low-level details instead of providing a high-level fix
> like subclassing a component of the compiler.
   Yes ! But I see no opposition in that with using a self-extensible LLL
to bootstrap the HLL. Again, a self-extensible LLL is to me some good
alternative to an explicitly bytecoded system (the LLL could be bytecoded
itself, or threaded, or translated to native code).

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"