[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: (BUG LISP) at MIT-MC, MRG at MIT-MC
- Subject: TRACE Package
- From: KMP at MIT-MC (Kent M. Pitman)
- Date: Sun, 7 May 78 18:03:00 GMT
- Cc: KMP at MIT-MC
- Original-date: 7 MAY 1978 1403-EDT
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.
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
(COND ((AND (> (LENGTH EXPR-PROP) 2)
(EQUAL (CADR EXPR-PROP)
(T (TERPRI TYO)
(PRINC '|;A NEW VERSION OF | TYO)
(PRINC EXPR-PROP TYO)
(PRINC '| EXISTS SINCE IT WAS TRACED. I AIN'T GONNA| 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...?