help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem advising nreverse.


From: Barry Margolin
Subject: Re: Problem advising nreverse.
Date: Thu, 17 Dec 2009 11:52:02 -0500
User-agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)

In article <mailman.13051.1260962896.2239.help-gnu-emacs@gnu.org>,
 Sergei Organov <osv@javad.com> wrote:

> Barry Margolin <barmar@alum.mit.edu> writes:
> 
> > In article <mailman.13027.1260909564.2239.help-gnu-emacs@gnu.org>,
> >  Sergei Organov <osv@javad.com> wrote:
> >
> >> > pjb@informatimago.com (Pascal J. Bourguignon) writes:
> >> >
> >> >> Sergei Organov <osv@javad.com> 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 ***


reply via email to

[Prev in Thread] Current Thread [Next in Thread]