TRACE Package

[KMP at MIT-MC (Kent M. Pitman)]

I have been getting some pretty strange results from TRACE these days. 
Yesterday I had something traced and I read in a new copy of it and when
I did UNTRACE it took away my copy leaving a null property list!
Today I had zeroed a property list [using (REMPROP '<thing> 'EXPR)] and
I did UNTRACE later (having traced <thing> before using the remprop command)
and when I did untrace it brought back the property list.

Proposal:

Why can't TRACE, in addition to what it does, keep a latch on the variables
it creates. Since they are gensymed, it could de an eq test on the current
arglist of expr by doing

((LAMBDA (EXPR-PROP)
	 (COND ((AND (> (LENGTH EXPR-PROP) 2)
		     (EQUAL (CADR EXPR-PROP)
			    THE-VAR-LIST-I-PUT-THERE-WHEN-I-TRACED-IT))
		(GO-AHEAD-WITH-UNTRACING))
	       (T (TERPRI TYO)
		  (PRINC '|;A NEW VERSION OF | TYO)
		  (PRINC EXPR-PROP TYO)
		  (PRINC '| EXISTS SINCE IT WAS TRACED. I AIN'T GONNA| TYO)
		  (TERPRI TYO)
		  (PRINC '|;MUNG WITH IT!| TYO)
		  (COMMENT DO NOTHING!))))
 (GET THING-TO-BE-UNTRACED 'EXPR))

Oh, well, if that doesn't work, I'd appreciate knowing why...?

				--kmp