Re: Why does evaluating a piece of Elisp code seemingly not expand a macro?

Re: Why does evaluating a piece of Elisp code seemingly not expand a macro?

[Marcin Borkowski]

On 2016-01-15, at 11:57, Oleh Krehel <ohwoeowho@gmail.com> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Why?
>
> Macro-expand the defun to get:
>
>     (defalias 'print-answer
>         #'(lambda nil
>             (message
>              "The answer is %s."
>              (forty-two))))
>
> `lambda' is a macro that /quotes/ its body. Therefore, the body of
> `defun' is not evaluated or expanded when it's defined.

Interesting.

1. Why is lambda sharp-quoted?  I remember reading (in Artur's blog)
that it shouldn't be.

2. I always thought that macros get expanded on compilation (or defining
the function).  If I evaluate all forms I've written about outside Org
(using C-M-x, for instance), the `forty-two' macro seems to get
expanded.

In the manual (info "(elisp)Expansion"), I could find this:

--8<---------------cut here---------------start------------->8---
   Note that Emacs tries to expand macros when loading an uncompiled
Lisp file.  This is not always possible, but if it is, it speeds up
subsequent execution.  *Note How Programs Do Loading::.
--8<---------------cut here---------------end--------------->8---

Does it mean that C-M-x is different than loading?  Or C-x C-e, for that
matter?  Is this covered by the manual?  (If not, it might need
correcting.)

> You probably wanted something like this instead:
>
>     (macroexpand-all
>      '(lambda nil
>        (message
>         "The answer is %s."
>         (forty-two))))
>     ;; =>
>     ;; (function
>     ;;  (lambda nil
>     ;;   (message
>     ;;    "The answer is %s."
>     ;;    42)))
>     
> Which could be wrapped in a new macro:
>
>     (defmacro defun-1 (name arglist &optional docstring &rest body)
>       (unless (stringp docstring)
>         (setq body
>               (if body
>                   (cons docstring body)
>                 docstring))
>         (setq docstring nil))
>       (list 'defun name arglist docstring (macroexpand-all body)))
>
> The above seems to work, at least superficially:
>
>     (symbol-function
>      (defun-1 print-answer ()
>        (message "The answer is %s." (forty-two))))
>     ;; =>
>     ;; (lambda nil
>     ;;   (message
>     ;;    "The answer is %s."
>     ;;    42))

Interesting, I will study this (but not today - it's 23:51 here, I'll
need sleep soon!)

> By the way, it might be more appropriate to ask similar questions on
> help-gnu-emacs@gnu.org.

I posted this reply there, too, though in view of what I wrote above
I still think this is Org-related.

> Oleh

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Why does evaluating a piece of Elisp code seemingly not expand a macro?

[Stefan Monnier]

> Does it mean that C-M-x is different than loading?

Yes.

> Or C-x C-e, for that matter?

As well.

> Is this covered by the manual?  (If not, it might need correcting.)

Not really.  The basic idea is that macroexpansion can take place
*anytime* (tho, before the code is actually executed).  If you care
about when expansion takes place you probably have a bug.


        Stefan

Re: Why does evaluating a piece of Elisp code seemingly not expand a macro?

[Marcin Borkowski]

On 2016-01-18, at 14:54, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Does it mean that C-M-x is different than loading?
>
> Yes.
>
>> Or C-x C-e, for that matter?
>
> As well.
>
>> Is this covered by the manual?  (If not, it might need correcting.)
>
> Not really.  The basic idea is that macroexpansion can take place
> *anytime* (tho, before the code is actually executed).  If you care
> about when expansion takes place you probably have a bug.

Does that mean that it's possible that a function definition contains
unexpanded macros?

Does that mean that `symbol-function' will expand them?

Does that mean that if I define a macro, then a function using that
macro, and then change the definition of the macro, the behavior of the
function is undefined?

Sorry for so many questions, but I really want to understand this.
(Also, when that happens, I might send a patch for the manual.)

>         Stefan

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Why does evaluating a piece of Elisp code seemingly not expand a macro?

[Stefan Monnier]

> Does that mean that it's possible that a function definition contains
> unexpanded macros?

Yes.

> Does that mean that `symbol-function' will expand them?

AFAIK it currently never happens there, but if your code relies on this
property it's probably got a bug.

> Does that mean that if I define a macro, then a function using that
> macro, and then change the definition of the macro, the behavior of the
> function is undefined?

Yes.


        Stefan