GNU bug report logs - #17498
24.4.50; This function has a compiler macro `yes--cmacro'.

Previous Next

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

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

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

From: Leo Liu <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; This function has a compiler macro `yes--cmacro'.
Date: Thu, 15 May 2014 23:05:18 +0800

Eval the following code

;;;; BEGIN
(defun yes ()
  )
(when nil
  (cl-define-compiler-macro yes (&rest _)))
;;;; END

,----[ C-h f yes RET ]
| yes is a Lisp function.
| 
| (yes)
| 
| This function has a compiler macro `yes--cmacro'.
| 
| Not documented.
| 
| [back]
`----

how is it possible? the compiler macro is defined at macro expansion
time?

Leo

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 17498 <at> debbugs.gnu.org
Subject: Re: bug#17498: 24.4.50;
 This function has a compiler macro `yes--cmacro'.
Date: Thu, 15 May 2014 15:43:11 -0400

> ;;;; BEGIN
> (defun yes ()
>   )
> (when nil
>   (cl-define-compiler-macro yes (&rest _)))
> ;;;; END

> ,----[ C-h f yes RET ]
> | yes is a Lisp function.
> | 
> | (yes)
> | 
> | This function has a compiler macro `yes--cmacro'.
> | 
> | Not documented.
> | 
> | [back]
> `----

> how is it possible? the compiler macro is defined at macro expansion
> time?

Pretty much, yes.  That's because the compiler macro is likely to be
needed/useful while compiling the rest of the file (before it gets
loaded).


        Stefan

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17498 <at> debbugs.gnu.org
Subject: Re: bug#17498: 24.4.50;
 This function has a compiler macro `yes--cmacro'.
Date: Fri, 16 May 2014 09:28:06 +0800

On 2014-05-15 15:43 -0400, Stefan Monnier wrote:
> Pretty much, yes.  That's because the compiler macro is likely to be
> needed/useful while compiling the rest of the file (before it gets
> loaded).

But this is different from emacs 22 and 23. And it looks
counter-intuitive. I would expect macro expansion not to do much other
than transforming the code passed in. So I am curious is current
behaviour due to the byte-compiler i.e. if we don't do it this way it
won't work?

Thanks,
Leo

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

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 17498 <at> debbugs.gnu.org
Subject: Re: bug#17498: 24.4.50;
 This function has a compiler macro `yes--cmacro'.
Date: Fri, 16 May 2014 10:59:41 +0200

Leo Liu <sdl.web <at> gmail.com> writes:

> Eval the following code
>
> ;;;; BEGIN
> (defun yes ()
>   )
> (when nil
>   (cl-define-compiler-macro yes (&rest _)))
> ;;;; END

FWIW (and because it was not obvious to me), it's due to
eval-and-compile:

(when nil
   (eval-and-compile (message "foo")))
=> foo is shown in *Messages*

Same with this :
(defmacro bar () '(eval-and-compile (message "foo")))
(when nil (bar))

This case could be "fixed" by optimizing `when' for a nil condition :

(defmacro new-when (cond &rest body)
  (declare (indent 1) (debug t))
  (and cond
       (list 'if cond (cons 'progn body))))

Then
(new-when nil (bar))
doesn't show anything.

-- 
Nico.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 17498 <at> debbugs.gnu.org
Subject: Re: bug#17498: 24.4.50;
 This function has a compiler macro `yes--cmacro'.
Date: Fri, 16 May 2014 08:24:57 -0400

> But this is different from emacs 22 and 23. And it looks
> counter-intuitive. I would expect macro expansion not to do much other
> than transforming the code passed in. So I am curious is current
> behaviour due to the byte-compiler i.e. if we don't do it this way it
> won't work?

Well, there's always some other way, but yes it's made so that it works
when byte-compiling.


        Stefan

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 17498-done <at> debbugs.gnu.org
Subject: Re: bug#17498: 24.4.50;
 This function has a compiler macro `yes--cmacro'.
Date: Sat, 17 May 2014 02:25:57 +0800

On 2014-05-16 08:24 -0400, Stefan Monnier wrote:
> Well, there's always some other way, but yes it's made so that it works
> when byte-compiling.

OK and thanks for the explanation. It took me by a surprise.

Leo

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 17498 <at> debbugs.gnu.org
Subject: Re: bug#17498: 24.4.50;
 This function has a compiler macro `yes--cmacro'.
Date: Sat, 17 May 2014 02:28:32 +0800

On 2014-05-16 10:59 +0200, Nicolas Richard wrote:
> This case could be "fixed" by optimizing `when' for a nil condition

NIL is used to show the compiler macro is always defined; it could be
any non-constant expression. But thanks for pointing me to
eval-and-compile.

Leo

Previous Next

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