GC considered incompatible with low-level programming

[Eric W. Biederman]

No this isn't as ridicolous as the now famous 
"goto considered harmful" thing by Dijstraka.

>From listening to our discussions, and looking at some of my one code
to implement some of my ideas it appears to me that low-level-coding
is incompatible in goals at least with having built-in garbage
collection in the language.

No one hardly wants to program in assembly language.
Why because it's a lot of work and you must be real familiar with the
machine, and most of all it's really hard to restructure your code if
you change your mind.

A low-level language is constructed to make the task of programming on
a machine easier and to some extent more portable.  That is to bang on
the hardware.  It has powerful constructs to make that job easier.
One of the most important of these is programmer beware, and no type
safety none!  To have a garbage collector implies at least a little
type safety so try to shoe horn it in at such a low-level is silly, or
from utsl:

    This is an important part of what I like about Forth. Forth's very lack 
    of stack frames is one of it's greatest strengths, IMHO. Sure, you can 
    mess up, but that's true of all good languages. ;-) I wouldn't want to 
    work in an idiot-proofed language, since I would probably be prevented 
    from doing most of the things I want to do.

We could gone on for a long time about the evils of combinding GC and
a low-level language, but that's just talk.  Instead I think we should
have a slightly different language model for tunes, a language/api stack.


1. Physical layer:
The physical layer is responsible for handling both the mechanical and
electriacl details of the physical machine the computation is to be
done on.   Basically making sure the parts of the machine can connect to
each other.  (to low for tunes to worry about)

2. Data-link layer:
The data-link layer is responsible for the hardware convetions,
handling such things as irqs, & error detection and recover in the
physical layer.  (still to low)

3. Compute layer:
This is the layer representated by opcodes in an assmebler.  It is the
machine before you start adding any code to it.

4. low-level layer:
This is the level of device drivers, and basic implementation.  The
coders of this level mostly use asm, C, or forth.  What is written
here is something that is very hard to implement at a higher level.

5. calling conventions & low-level idiot proofing layer:
At this level coding is much more restricted, as strong it provides
for strong garantees about the kind of code you are writing.  The most
important part though is that you can only hit the hardware by call
through a routine written at the in the low-level layer.
Algorithmically and support wise this layer hardly has anything.
Everthing from this level upword ports.
This is about the level where scheme can be used.

6. Mid-level layer:
At this level there are a lot of API's and it is comfortable to
program.   The programmer is still mostly concerned with the nitty
gritty details of algorithms.  This is about as high as C can go.

7. High-level layer (Tool assisted):
At this level the tools that assist you to program become almost more
important then the language itself.  This I suspect is about the level
of APL.  But also it is the level of real nice IDE's

8. Very-High-level layer (For Everbody):
This is the level of macro's in code, and customizable interfaces, and
point and super point and click.  Everyone should be able to program
at this level