GC considered incompatible with low-level programming

[Eric W. Biederman]

   On Sun, 28 Apr 1996, Eric W. Biederman wrote:
   > 
   > 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.

   I guess I'm no one, now. ;-)

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

   First of all, there is a difference between having stack frames and type 
   safety! Stack frames do not require type safety, nor does type safety 
   require stack frames.

Darn I knew I should have take out that first sentence of the quote!
What I was  really refering to the rest about messing up & good
languages.  What GC does is idiot-proof storage management.  

What you say is true, but a stack frame makes finding out the type by
the collector much nicer.

   Second, let's wait a little while before we give up on the current plan.
   Before we accept your claim (GC considered incompatible with LL 
   programming), why don't we prove you right or wrong experimentally. 
   (This will prove you're not acting like Djikstra. ;-) That is, try to do it, 
   then see if it's impossible. Also, as a last resort, we could always 
   develop an environment where hand-written LLL isn't GC-ed, but HLL
   output is.

I agree.

   Also, GC isn't in exactly the same class as the idiot-proofing I'm 
   refering to. By that, I mean that a language shouldn't be designed to 
   prevent the programmer from making mistakes. GC doesn't, in fact, do 
   this, rather GC exists to clean things up, regardless of mistakes.

Well GC is designed to prevent mistakes in storage management.  To
create code that is idiot-proofed 

   The whole point of this list, is to discuss ways of implementing the LLL. 
   At present, we're still exploring the Forth+GC concept. I'm not ready to 
   give up yet, since I don't know that much about GC implementation yet.

I'm not ready to give up.  What I am saying though is that if we can't
make it work we shouldn't sweat it.  Currently everything I have seen
as solutions have had either compromised efficiency (lots of type
tagging, off of the heap) or compromised flexibility (my proposal).

Also I'm saying that a finer grain system of language levels versus
simply HLL, LLL is probably a better concept anyway.  Not that forth
couldn't be at several levels.

For example:
LLL: name 
some code ;  / for unchecked code
: name 
some other code ;  / if you want to let the system track pointers for you.

In the LLL flexibility and efficiency are very important to the LLL,
so if we can't make it work for pure forth code, the HLL will have to
generate code that is some more restricted, and code that wants to be
LLL GC'ed will have to be restricted by the programmer.

The one system I have seen that has stacks of essentially anonymous
objects and is type safe are parsers.  But parsers aren't quite forth,
and are restricted to implementing pushdown automata, so I have to
look and see if the techniques can be adapted.  I haven't had the time
yet.

Also I have 3 finals tommorrow so I should shut up and study.

Have fun!

 BYE!!! 
   
   Ahh!!!!!

Eric