GNU bug report logs - #15296
24.3.50; A macro object does not necessarily have `lambda' as its cadr

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Sat, 7 Sep 2013 05:41:02 UTC

Severity: minor

Found in version 24.3.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15296 in the body.
You can then email your comments to 15296 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#15296; Package emacs. (Sat, 07 Sep 2013 05:41:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 07 Sep 2013 05:41:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; A macro object does not necessarily have `lambda' as its cadr
Date: Fri, 6 Sep 2013 22:39:58 -0700 (PDT)
AFAICT, (elisp) `Defining Macros' is the closest thing we have to doc
telling you how to test whether a Lisp object is a macro.  There is no
`macro-p' predicate or similar in Emacs Lisp, unless I'm missing
something.  (Shouldn't there be?)

Anyway, this Elisp manual node says that a macro is a list whose car is
`macro' and whose `cdr' is a lambda expression.  That's not true if the
`defmacro' was byte-compiled.  The macro is then a list whose car is `macro'
but whose cdr is byte code, AFAICT.  So this will not work, for example:

(defun macro-p (obj)
  (and (fboundp obj)
       (let ((def  (symbol-function obj)))
         (and (consp def)
              (eq (car def) 'macro)
              (eq (cadr def) 'lambda)))))

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-08-23 on ODIEONE
Bzr revision: 113986 rgm <at> gnu.org-20130823185841-zoy6h1qk433ibrlf
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#15296; Package emacs. (Sat, 07 Sep 2013 11:35:02 GMT) Full text and rfc822 format available.

Message #8 received at 15296 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15296 <at> debbugs.gnu.org
Subject: Re: bug#15296: 24.3.50;
 A macro object does not necessarily have `lambda' as its cadr
Date: Sat, 07 Sep 2013 13:34:27 +0200
Drew Adams <drew.adams <at> oracle.com> writes:

> AFAICT, (elisp) `Defining Macros' is the closest thing we have to doc
> telling you how to test whether a Lisp object is a macro.  There is no
> `macro-p' predicate or similar in Emacs Lisp, unless I'm missing
> something.  (Shouldn't there be?)

There is `macrop' in subr.el (since some months ago, I think).

> Anyway, this Elisp manual node says that a macro is a list whose car
> is `macro' and whose `cdr' is a lambda expression.  That's not true if
> the `defmacro' was byte-compiled.

Confusing, indeed.


Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#15296; Package emacs. (Sat, 07 Sep 2013 14:24:02 GMT) Full text and rfc822 format available.

Message #11 received at 15296 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 15296 <at> debbugs.gnu.org
Subject: RE: bug#15296: 24.3.50; A macro object does not necessarily have
 `lambda' as its cadr
Date: Sat, 7 Sep 2013 07:23:39 -0700 (PDT)
> > AFAICT, (elisp) `Defining Macros' is the closest thing we have to doc
> > telling you how to test whether a Lisp object is a macro.  There is no
> > `macro-p' predicate or similar in Emacs Lisp, unless I'm missing
> > something.  (Shouldn't there be?)
> 
> There is `macrop' in subr.el (since some months ago, I think).

Wow, that's weird.  And thank you.  That was the first thing I looked for
(the second was `macro-p'), and for some reason I didn't find it (and I'm
using only a recent Emacs 24 build for this testing).

But you are right.  I must have somehow checked for that in a different
Emacs version.  Anyway, that solves my problem wrt testing the type.

> > Anyway, this Elisp manual node says that a macro is a list whose car
> > is `macro' and whose `cdr' is a lambda expression.  That's not true if
> > the `defmacro' was byte-compiled.
> 
> Confusing, indeed.

Not confusing, actually.  It's quite clear.  And wrong, unfortunately.
So AFAICT this should remain open for now, as a doc bug.




Reply sent to Stefan Monnier <monnier <at> iro.umontreal.ca>:
You have taken responsibility. (Sun, 08 Sep 2013 18:03:01 GMT) Full text and rfc822 format available.

Notification sent to Drew Adams <drew.adams <at> oracle.com>:
bug acknowledged by developer. (Sun, 08 Sep 2013 18:03:02 GMT) Full text and rfc822 format available.

Message #16 received at 15296-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15296-done <at> debbugs.gnu.org
Subject: Re: bug#15296: 24.3.50;
 A macro object does not necessarily have `lambda' as its cadr
Date: Sun, 08 Sep 2013 14:01:53 -0400
> `macro' and whose `cdr' is a lambda expression.  That's not true if the

I changed it to say "function" instead.


        Stefan




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 07 Oct 2013 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 11 years and 336 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.