🚀 go-pugleaf

In article <21495.1993Jan5.174456@bcars148> emcoop@bnr.ca (hume smith) writes:
>prompted by boredom...  the only thing i wonder (it just occurred to me) -
>if there were no unbound symbols when a garbage collection occurred, would
>the special symbol disappear?  it's unlikely to happen, but still...

Hume,
 The first part of your message appears to be missing.

>;;; XLisp knows whether a symbol is bound or not by whether a particular
>;;; symbol is bound to its value or function field.
>;;; that symbol is internal; i.e. in the obarray.  this can make for
>;;; nasties when you want to manipulate the obarray.  it also creates
>;;; certain strange situations:
>;;;  (setq z '*unbound*)  ->  *unbound*
>;;;  (boundp z)  ->  nil
>;;; it would probably be better if that symbol were not in the
>;;; obarray. 

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.

Tom


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

In <13142@sail.LABS.TEK.COM>, toma@sail.LABS.TEK.COM (Tom Almy) said:
> Hume,
>  The first part of your message appears to be missing.

but apearances can be deceiving!  it was all there.  i guess i really
should be ambitious enough to capitalise.

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

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

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.  surely the "figure
out what's used" part of gc would just mark it used, and the "build freelist" part
would just not see it, it not being in a segment.  so it should work.

i've obviously got to wade through the gc code and find out.

it does, still, need treatment in save/restore.

another possibility - now that nil is an actual symbol, how hard would it be to
use the NUL pointer?
--
Hume Smith                      Wenn ich des Tages nicht dreimal
hume.smith@acadiau.ca           mein Schaelchen Coffee trinken darf,
emcoop@bnr.ca              //   so werd' ich ju zu meiner Qual
                         \X/    wie ein verdorrtes Ziegenbraetchen.

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

In article <21495.1993Jan5.174456@bcars148> emcoop@bnr.ca (hume smith) writes:

>  (let* ((ind (hash "*UNBOUND*" (length *obarray*)))
>	 (ls (aref *obarray* ind))
>	 (z (car (member "*UNBOUND*" ls :test #'string= :key #'symbol-name))))
>    (unless (boundp 'z)
>      (setf (aref *obarray* ind) (remove "*UNBOUND*" ls :test #'string= :key #'symbol-name))))

of course boundp doesn't work right (i.e. the way i wish it did :-)
with "letted" variables...  this all has to be done in the global environment.

(setq ind (hash "*UNBOUND*" (length *obarray*))
      ls (aref *obarray* ind)
      z (car (member "*UNBOUND*" ls :test #'string= :key #'symbol-name)))
(unless (boundp 'z)
  (setf (aref *obarray* ind) (remove "*UNBOUND*" ls :test #'string= :key #'symbol-name))))
  
i just LOVE saying stupid things in front of the whole world :-)

to make up for it:  here's a definition with-open-stream.  not much use
in `standard' XLisp, but nice with my client and accept accept functions.
and it can be used on an already-open stream, of course...  the uninterned
symbol protects against things like
     (with-open-stream (x z) (setq x 'b))

(defmacro with-open-stream (sym-stream &rest body)
  (let ((sym (first sym-stream))
        (stream (second sym-stream))
	(gsym (gensym)))
    `(let* ((,gsym ,stream)
	    (,sym ,gsym))
       (unwind-protect 
           (progn ,@body)
         (close ,gsym)))))
--
Hume Smith
hume.smith@acadiau.ca
emcoop@bnr.ca