HLL is not against LLL

[Francois-Rene Rideau]

>>> The HLL implementation has to be written in itself (or a subset of
>>> itself) since reflectivity is a requirement (one might want to observe
>>> or modify the implementation dynamically).
>
>>    And the LLL is this subset of the HLL we write it into !
> 
> I thought the LLL was an intermediate language into which you
> wanted the compiler(s) to produce code. (LLL as a target language)
> But it seems you want to use it as a host language, to write compiler(s)
> in that language. I thing that would be a "bad" thing, see below.
   The LLL is all that and more, and at the same time, it is not meant
as a "canonical" way to do things, just a sample portable (yet not
completely inefficient) implementation: a first version of the compiler
will sure produce LLL code; the LLL will be a host language for the
low-level parts of the first version of the compiler; but the LLL with
naturally *extend* into the HLL, so that the LLL-specific part of the
hosted compiler will be as small as possible (and further versions
can replace it by something else, if necessary).
   I agree that a completely separate and artificial LLL wouldn't be any
good, but I don't think it's the case with this LLL project.


>>    I am still convinced that a LLL is a very good speed-up for the
>> development of a computing system.
> 
> 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 practical way to bootstrap the HLL in a portable way.
It replaces both bytecodes, and the "subset" of the HLL required.
Remember we're using a *self-extensible* 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. 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.
   Who says the LLL cannot have an object system ? An object system
is easy to add to a self-extensible language (see FORTH and Scheme
object systems); actually, it is the first thing we will add to the LLL
after raw I/O capabilities.

--    ,        	                                ,           _ 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/"