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

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

[Leo Liu]

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

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

[Stefan Monnier]

> ;;;; 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

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

[Leo Liu]

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

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

[Stefan Monnier]

> 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

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

[Leo Liu]

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

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

[Nicolas Richard]

Leo Liu <sdl.web@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.

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

[Leo Liu]

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