HLL is not against LLL

[Patrick Premont]

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

Yes. But it has to be usefull. I think we should discuss what is the LLL
(what features it has and doesn't have) and why we need 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.

Why do we need language independence at that level and a _standard_
intermediate language ? You say below that language independence would
be acheived through the HLL.

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

I don't see how that requires a LLL as a target language. (If that is
what you implied)

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

I'm not sure what you mean by an interactive environement. I assume you
mean an interpreted HLL. But this is easy to do. So I'm not sure.

I don't know much about FORTH but it seems very bare-bone. That
means we'd have to do a lot of work to build it up to a high level
language. Starting with a high level language would save this work.

Here's my suggestion. Use Dylan as a host language for the HLL
compiler.  Start with a free implementation and tweak it to make it
more reflexive (allow subclassing of everything including functions).
Now write a Dylan+ compiler in Dylan that produces machine code
(change some back-end objects to retarget to a different platform).
The new compiler produces a run-time which has a specific structure.
All of that structure (down to the last bit) is reified (made real,
described by objects) and available in Dylan+. So you have objects
that define calling conventions, object representations, garbage
collectors, identificators/pointers, bits, machine operations, ... and
you can use them to change the low-level structure of the
implementation at run-time.  The compiler is made availabe at run-time
since it is writen in Dylan and can be compiled by itself.

I suggest Dylan because it is very dynamic and reflexive and a good
part of it's implementation has been written in Dylan. Our Dylan+
compiler wouldn't have to worry about that part of the language. Dylan
has a nice object system. Function calls have no distinguised receiver
and I think that's good (it uses generic functions). It has
first-class classes, methods, generic-functions, types... We would
only have to extend that list in Dylan+ so that it becomes even more
flexible.

Other high-level, OO, dynamic, reflexive languages with a free
implementation may be just as good but that's the only one I know.

Adding lazy evaluation should be possible without changing the language
too much. We would probably need to split the function class hierarchy
in pure and with-side-effects subtrees to know when not to do lazy
evaluation.

Expanding the type system to support arbitrary conditions is probably more
difficult but possible.

No matter what language we start from, we'll have to write TUNES
specific features and it won't be easy. But since there are languages
which already do some of the things we want, why not start from them ?

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

To me, being object-oriented implies being high-level. So it seems that
we don't understand what each other means by a LLL. We should definitely
solve that problem.

I've seen OO extentions to Scheme which represented objects as vectors
starting with an integer. It was unsafe and slow. But maybe these
problems are avoided in OO extensions of FORTH. Anyway, I'm sure we
could start from FORTH but the more bare-bone the first language,
the more work we have to do. I'd rather not have to implement
collections (lists, hash-tables, stretchy-vectors, ...) because
they would very usefull if we had them in the initial language (Dylan has
them) and implementing them is a lot of work which has already been done
in other languages. The migration project could find a way to translate
them from Dylan (or whatever) to our HLL but we would not befinit until
the project is almost completed.

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

So how low do we start ?  FORTH ? Dylan ? ...
I suggest we start high but add low-level control to our initial language.
Starting too low seems like more work for similar results.

As for the target language, I suggest we don't use the same as the
host language and go directly to machine code.

Geeze, 3 hours to write that ! I've got to stop correcting myself so much.
I'll let you guys do that.

Patrick