GC considered incompatible with low-level programming

[Nathan Hawkins]

On Sun, 28 Apr 1996, Eric W. Biederman wrote:
[discussion of GC vs. idiot-proofing]
> 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.  

I don't agree. The GC tries to clean up after idiots. You can still screw 
up, it's just that the GC tries to prevent it from breaking things.
Manually allocating memory is error-prone. Now an idiot-proofing approach 
would something like automatic stack variables, without the ability to 
return or pass a pointer to one. GC seems more like the fatalistic 
approach: errors _will_ be made, so we attempt to find and fix them after 
the fact, and in the process re-define them as non-errors.

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

Depends on how we do things - if we use pointer/integer distinctions, the 
only remaining problem is identifying blocks, and their types. This could 
be done with bits in the pointer.

[I said some things, and then I said:]
> ... 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.

This might not be a bad idea actually.... See below.

>    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 

I wouldn't say that. It's still possible for someone to keep a pointer to 
an object around forever, for no good reason, and a GC can't fix that, 
can it?

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

That's fine with me. I have no huge stake in doing GC, anyway. But I'm 
trying to go along with it, 'cause I could use the help developing an 
environment that has the things I really want. (Detailed in a previous post.)

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

This might be a very good idea. Problem is, the GC would be in a really 
bad fix if we were to mix these into different heaps. To do this we'd 
have to say that all LLL unchecked code must be separated from LLL/HLL 
checked code. However, the GC'ed heap should be able to point to a 
un-GC'ed heap without problems, and if we implement my cross-heap pointer 
idea, we might be able to do the reverse. (If that idea can be made to 
work. ;)

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

What do you mean anonymous objects? If you mean that the GC can't figure 
out what they are, no we shouldn't have that. We will have to provide 
some means of detecting what type a stack element is. I simply would 
rather not use stack frames to do this, since it would break Forth.

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

Yeah, I'm can sympathize with you there, although I'm not in school, I 
have a full-time job, and a certain government agency I'm having to deal 
with...

*utsl*