Some comments on HLL/LLL from the peanut gallery

[Patrick Premont]

The message I receive was dated December 31st 1995 so I almost lost
it in my pile of old messages. Your clock must be off.

>   So, Tunes is more like the system software found on the old 8 bit Atari's,
> Commodore 64s and Apple ][s in that the language (BASIC in this case) is the
> OS.  Or the Xerox Star with Smalltalk.  And many Forth based systems are
> like this as well.  

>   Well, I don't see systems around like that anymore, maybe because they're
> not practical, but on the other hand, it might be that it might be time for
> such systems to make a come back.  

Not practical because you can't port to the OS software written in
another language (and can't write in another language) ? Well, we may
eventually support other languages but that's not what is interresting.
We want to enable the creation of better software through a better OS
& language combination. There isn't much that can be done to enhance
your old C code short of rewriting it.

>   But I would suggest you drop any notions of being able to evolve any code 
> you write the HLL in into HLL.  Write it once in <pick your language>.  Once
> you get the HLL going, start over from scratch, writing the HLL in the HLL. 
> You'll end up with something that is cleaner.

When the modifications to the language are very important then yes it
is better to rewrite everything. But the language will also evolve by
smaller steps at times which will not warrant a complete rewrite.
I understand you concern though. It would be easy to end up with a mess of
code which was written at very different times in very different languages.
We should probably identify the code fragments with the version of
the language they were written in, this way we could do major clean ups
by rewriting the old stuff.

>   Okay, so at this point I'll apply my same argument:  Who cares what the
> LLL is?  As long as the HLL can talk to the LLL, reguardless of what the LLL
> is, why bother with defining an LLL?

We'll need to define it to make sure things interface corretly at the
low level. However this will be for our purposes only. Once the system
is complete, the LLL will not be of any concern. Except for those
who wish to have fun in the low level stuff but then they won't have
to follow the LLL conventions, they might make up their own (but big
brother will be watching to make sure they don't screw up other stuff).
So yes the LLL is arbitrary and could be anything. But at first it
has to be something and we must know what that something is precisely.

>   Another suggestion, check out Java.  It may not meet the requirements for
> the HLL, but as far as the LLL goes, it's already a bytecode system where
> Java binaries can run, unmodified, on multiple systems.

Maybe it could serve as an inspiration.

> > Only the HLL will be available to users/programs at first. We intend
> > to make it so well intergrated into the OS and so great that no one
> > will want to use other languages. 
> 
>   So I can hack the hardware in the HLL, while at the same time, compute e
> to 1,000,000 digits, AND write a natural language parser?  I'm sorry, but I
> still don't buy the "All singing, all dancing" language. We have a few of
> those, the most notable being Ada, another C++.

If that is what they attempted to do, they failed very badly.  I
beleive that much better can be done. But I`m not saying that it will
be better at everything than every other possible language. Rather :
Better at most things than most languages and able to accomodate the
other languages when that is not the case.

>  There's a reason why
> certain languages evolve (or are written):  to precisely solve a problem in
> a particular domain.  Fortran for numerical analysis.  C for systems work. 
> Lisp for AI.  

And what happens when you want to make an action game with great AI and
with physical simulations ? Trouble.

>   -spc (Languages limit what constructs we can devise ... )

That's what reflexivity aims to counter. And we want plenty of it in Tunes.

Don't take this the wrong way but I'd rather try to build the system than
try to prove, without doing it, that it can be done. The objectives are
not formal (like most things in computer science) and formalizing is
the first requirement to build a proof. Once the system has been built
on the other hand, it should be reasonably easy to check if we have succeded.
I'm convinced it is possible but I don't know if we'll have the resources
to prove it.

Patrick