🚀 go-pugleaf

In article <21495.1993Jan6.173532@bcars148> emcoop@bnr.ca (hume smith) writes:
>In <13142@sail.LABS.TEK.COM>, toma@sail.LABS.TEK.COM (Tom Almy) said:

>btw Tom, have you gotten any mail from me lately, like, the last
>few days?  i've got a sneaking suspicion my mail connections are
>downn...

No mail, it's down, I guess.

>> You know, I don't know why it wasn't done that way in the first place. If 
>> *unbound* was not interned in the first place then everything should work 
>> fine (however, special treatment would be needed in the gc, as you seem 
>> to be alluding to, and also in save/restore.

>what i was actually alluding to was that once my slip of excessively-commented
>code was run, if ever EVERY symbol was boundp and fboundp (and whatever other
>pointers *unbound* got used in), AND a gc was done, the special symbol would
>be collected, probably making ripe chunder later.

Yes, that's why I stated "special treatment" in the GC. It would need to be
explicitly marked, just like objects in the stacks.

>i've been theorizing a little on how to fix it... i'm wondering, if s_unbound pointed
>to a static (C compile-time) piece of memory, what would hapen.  

After the post, I thought of that too. There is no real reason that a normal 
symbol would have to be used (same case as NIL).

As to making the value NULL (since NIL != NULL), no thanks! I'm just glad I 
finally cleaned out that can of worms!

Tom
-- 
Tom Almy
toma@sail.labs.tek.com
Standard Disclaimers Apply