my flaming

[Juliusz Chroboczek]

  Well, after receiving the standard reaction for a flamebait, I read
my posting again, and came to the conclusion that it was one indeed.
I believe I should apologize to everyone who felt offended.
  I think I simply overreacted to JVS's message; I'll try to make my
position clearer this time.

BTW: I used the word > mirific.  and the standard reaction was {?}
> I've checked: it does *not* exist.  I shall use a dictionary in the
> future.  What I meant was basically that I thought you were
> expecting a miracle.  Furthermore, I had the bad taste to make an
> error in the initials of a poster: > JVC's answer seemed to imply
> that he..  I am not a VCR (JVS)!
  Sorry.

  I think that most of the discussion comes from a difference of
understanding of what the LLL should do.  So let me answer your
questions, and *then* say what it is that we misunderstood about each
other.

> 2. I do believe however that  it IS possible to create a "symbolic
> assembly language" (convention) that can be used on most (all?) 
> current machines. Good assembly language programmers only use a small 
> proportion of the wide variety of instructions available on most 
> current processors. You only _need_ a small selection of instructions 
> to execute most tasks.
  Yes, but what we want is *the same efficiency as for native code*.
What we want is a somewhat higher level language than assembly, so
that it can be automatically translated into native code that takes
into account things such as pipeline timings and so forth.

> 3. This symbolic assembly language can then be used to create HLL(s) 
> that do useful work on all the machines, with a common "core". I do 
> _not_ mean that you can now take code in any arbitrary language and 
> exepct it to run faultlessly in "our" system.
  Not if you expect your HLL implementation using the LLL to be of
comparable efficiency as a native one.

> 5. If you have formal proof that the above is bullshit, please submit 
> it.
  No formal proof, but a fair amount of coincidental evidence (the
same sort of stuff that makes us believe in Church's Thesis).
Basically, what you are trying to do is to get a `doubly universal'
intermediary language for compilers.  This is an old dream, and quite
a few attempts have been made to achieve it (there's something about
the early attempts in the Dragon Book).  The most successful has
probably been the GCC compiler, which works quite well on 32 bit
machines with a flat memory model (there are other limitations I don't
remember), and only with very similar languages (extending the
intermediary representation to handle Ada (yuck!) was quite a big job).

[some stuff about Lisp and fucking deleted]

  Allow me a short paranthesis about Lisp.
  Well, the problem with Lisp is that either you lose on memory or
speed.  For instance, you get speed that is about 90% that of C if you
can accept a 4 Meg runtime and a 10 Meg compiler (CMU CL; it's free).
You can get full CL, but a bytecode implementation (10% of C's speed)
in 1.5 Meg (Bruno Haible's CLISP; free too).  And you can get full
Scheme with about the same speed in 500K (Aubrey Jaffer's SCM; free
again).  I advise you have a look on the latter two (how much speed do
you need when you can compile the inner loop of your code in C?).
  References by e-mail if you're interested.

[...]
> I think you should read my letter again. I think you missed the point 
> completely.
[...]
> And now it's an assembler. The word to focus on is **interpreter**
[...]

  Well, basically, the problem is that we imagine completely different
things while speaking about the LLL.  I think you imagine an
interpreted bytecode, and I don't see how you expect to have efficient
code someday (I do use compilers that generate bytecode, but I also
generate native code sometimes; I would strongly resent the OS to have
me use bytecode systematically).  Fare focuses much more on the HLL,
while I thought we were speaking about an intermediary code, generated
by the compilers, distributed, and then translated into native code by
a code generator specific to the machine you want it to run on.
  Both points of view are very unsatisfactory: yours, because it is
very limiting; mine, because it is, as I tried to prove, impossible.
                                    JCh