[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 ***
- Re: Problem advising nreverse., (continued)
- Message not available
- Re: Problem advising nreverse., Pascal J. Bourguignon, 2009/12/14
- Re: Problem advising nreverse., Sergei Organov, 2009/12/14
- Message not available
- Re: Problem advising nreverse., Pascal J. Bourguignon, 2009/12/14
- Re: Problem advising nreverse., Sergei Organov, 2009/12/14
- Message not available
- Re: Problem advising nreverse., Pascal J. Bourguignon, 2009/12/14
- Re: Problem advising nreverse., Sergei Organov, 2009/12/15
- Re: Problem advising nreverse., Sergei Organov, 2009/12/15
- Message not available
- Re: Problem advising nreverse., Pascal J. Bourguignon, 2009/12/15
- Message not available
- Re: Problem advising nreverse., Barry Margolin, 2009/12/15
- Re: Problem advising nreverse., Sergei Organov, 2009/12/16
- Message not available
- Re: Problem advising nreverse.,
Barry Margolin <=