From ... Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!134.222.94.5!npeer.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: trace calls from within mapcar or similar functions References: <997124259.103256@cnn> Mail-Copies-To: never From: Erik Naggum Message-ID: <3206118893924779@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Aug 2001 20:34:56 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader1.kpnqwest.net 997130096 193.71.66.49 (Mon, 06 Aug 2001 22:34:56 MET DST) NNTP-Posting-Date: Mon, 06 Aug 2001 22:34:56 MET DST Xref: archiver1.google.com comp.lang.lisp:14081 * "Martin Simmons" > In LW, TRACE and UNTRACE modify the symbol function cell, not the > original function object. I'm not sure if it is conforming or not, but > the reason that #' returns the original function object is to prevent the > tracing function getting stuck in some data structure making it > impossible to untrace. > > E.g. > > (defun foo ()) > (trace foo) > (setq *foo* #'foo) > (untrace) > (funcall *foo*) ; would it be useful if this printed trace info for ever more? If you could add something in or to the function object itself to cause tracing, you would obviously remove it upon untracing, just like you would for the functional value cell of the symbol. This requires that the function object is more than just some code. In every Common Lisp implementation I have seen, this is the case. From a casual inspection of LispWorks for Linux, it appears to be true there, too. Even if you redefine the function after it has been requested traced, you can make sure the trace flag is turned off if you remember which function objects you have modified for what reason. ///