From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry Margolin Newsgroups: gmane.emacs.help Subject: Re: Problem advising nreverse. Date: Thu, 17 Dec 2009 11:52:02 -0500 Organization: A noiseless patient Spider Message-ID: References: <87skbg8jww.fsf@galatea.local> <87bpi1n1z7.fsf@galatea.local> <873a3dmvef.fsf@galatea.local> <87pr6hl9s4.fsf@galatea.local> <873a3dknyz.fsf@galatea.local> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1261071925 30849 80.91.229.12 (17 Dec 2009 17:45:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Dec 2009 17:45:25 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Dec 17 18:45:18 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NLKPe-0000D7-Ge for geh-help-gnu-emacs@m.gmane.org; Thu, 17 Dec 2009 18:45:18 +0100 Original-Received: from localhost ([127.0.0.1]:50904 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NLKPe-0003BP-4r for geh-help-gnu-emacs@m.gmane.org; Thu, 17 Dec 2009 12:45:18 -0500 Original-Path: news.stanford.edu!usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!news2.euro.net!news.mixmin.net!feeder.eternal-september.org!eternal-september.org!news.eternal-september.org!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 57 Original-X-Trace: news.eternal-september.org U2FsdGVkX1+PmYoB6ving3+G/eeB4Mzxhum58efqX/IoT51azczNPUuvXxIR1UYocIHFAaT3PHiCWVUKfiAwYixLp+c4FAdMySiV9gYZyRWBZsGq74sA0CXPimZlg7zKSRPzbeoC6pg= Original-X-Complaints-To: abuse@eternal-september.org Original-NNTP-Posting-Date: Thu, 17 Dec 2009 16:52:03 +0000 (UTC) User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) X-Auth-Sender: U2FsdGVkX19dH+aUz4CPZNuHEfgoA2JPqFU59SMflYk= Cancel-Lock: sha1:SdaP70/YnNEOfzIBie+hUXFZWe4= Original-Xref: news.stanford.edu gnu.emacs.help:175629 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:70703 Archived-At: In article , Sergei Organov wrote: > Barry Margolin writes: > > > In article , > > Sergei Organov wrote: > > > >> > pjb@informatimago.com (Pascal J. Bourguignon) writes: > >> > > >> >> Sergei Organov writes: > >> >>> I still wonder if it's documented somewhere in some manual when > >> >>> defadvice doesn't actually work. It seems it is not there in the Elisp > >> >>> manual, or did I miss it? > >> >> > >> >> See: (info "(elisp)Advising Primitives") > >> > > >> > Well, but I didn't find even single word there describing cases when > >> > it does not work to advise a funciton. > >> > >> Sorry, my mistake. In fact, this topic does tell about when advice won't > >> work, but it tells exactly opposite to what actually happens: > >> > >> "Calls to the primitive from Lisp code will take note of the advice, but > >> calls from C code will ignore the advice." > >> > >> Now, in my case `nreverse' is called from Lisp code, not from C code, so > >> according to the manual advice must work, right? And there is no single > >> word about differences in behavior due to byte-compiling. > > > > Byte compiling effectively changes it to a call from C code, because the > > byte code is a direct reference to the primitive. "Called from Lisp > > code" means interpreting Lisp source code, since that indirects through > > the function name, which is where advice is stored. > > I do understand what you are saying, but I can't persuade myself to > believe that "calls from C code" include "calls from byte-compiled Lisp > code" in general. As far as I understand, byte-compiled Lisp code is > never seen by a C compiler and can't be compiled by a C compiler, so > it's not C code, thus calls from byte-compiled code are not calls from C > code. IMHO it should be explicitly specified in the documentation that > calls to a primitive from byte-compiled Lisp code will ignore the > advice, provided this is feature indeed. I agree that the documentation should say this explicitly. What's presumably going on is that nreverse is a primitive byte-code operation. The code is presumably an index into a table of C function pointers, so the byte code interpreter simply calls those function directly. That's why it's equivalent to calling the function directly from other C code. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***