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

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

[Marcin Borkowski]

This piece of code:


#+BEGIN_SRC elisp :results value verbatim :exports both
  (defmacro forty-two ()
    (* 6 7))

  (defun print-answer ()
    (message "The answer is %s." (forty-two)))

  (symbol-function 'print-answer)
#+END_SRC


yields this:


#+RESULTS:
: (lambda nil (message "The answer is %s." (forty-two)))


and not that:


: (lambda nil (message "The answer is %s." 42))


Why?

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

[Oleh Krehel]

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.

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

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

Oleh

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

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

[Samuel W. Flint]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

>>>>> Marcin Borkowski writes:

MB> This piece of code: #+BEGIN_SRC elisp :results value verbatim
MB> :exports both (defmacro forty-two () (* 6 7))

That is not a macro.  That's a function.  The return value of a macro
(the result of the last expression in the implicit progn) needs to be a
(quasi-)quoted expression.

This macro simply evaluates to 42.  This should be a function.

If you want a macro, you could have:

#+BEGIN_SRC: emacs-lisp
  (defmacro forty-two ()
            '(* 6 7))
#+END_SRC

For what you want, you could have it be:

#+BEGIN_SRC: emacs-lisp
  (defmacro forty-two ()
            `,(* 6 7))
#+END_SRC


[...]

HTH,

Sam

-- 
Samuel W. Flint
4096R/266596F4
      (9477 D23E 389E 40C5 2F10  DE19 68E5 318E 2665 96F4)
(λs.s s) λs.s s

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

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

[Nick Dokos]

swflint@flintfam.org (Samuel W. Flint) writes:

>>>>>> Marcin Borkowski writes:
>
> MB> This piece of code: #+BEGIN_SRC elisp :results value verbatim
> MB> :exports both (defmacro forty-two () (* 6 7))
>
> That is not a macro.  That's a function.  The return value of a macro
> (the result of the last expression in the implicit progn) needs to be a
> (quasi-)quoted expression.
>

Not so. 

> This macro simply evaluates to 42.  This should be a function.
>
Maybe it should be a function, but it *is* a macro:

--8<---------------cut here---------------start------------->8---
(defmacro forty-two () (* 6 7))
==> forty-two
(symbol-function 'forty-two)
==> (macro lambda nil (* 6 7))
--8<---------------cut here---------------end--------------->8---


> If you want a macro, you could have:
>
> #+BEGIN_SRC: emacs-lisp
>   (defmacro forty-two ()
>             '(* 6 7))
> #+END_SRC
>

That's a different macro:

--8<---------------cut here---------------start------------->8---
(defmacro forty-two () '(* 6 7))
==> forty-two
(symbol-function 'forty-two)
==> (macro lambda nil (quote (* 6 7)))
--8<---------------cut here---------------end--------------->8---

--
Nick

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

[Marcin Borkowski]

On 2016-01-15, at 22:10, Samuel W. Flint <swflint@flintfam.org> wrote:

>>>>>> Marcin Borkowski writes:
>
> MB> This piece of code: #+BEGIN_SRC elisp :results value verbatim
> MB> :exports both (defmacro forty-two () (* 6 7))
>
> That is not a macro.  That's a function.  The return value of a macro
> (the result of the last expression in the implicit progn) needs to be a
> (quasi-)quoted expression.

IIUC, a macro is a function - a function returning a Lisp form.

> This macro simply evaluates to 42.  This should be a function.

Yes, I wanted it to evaluate to 42.  I expected the constant 42 in the
code.  (And this is what happens if I evaluate these forms outside an
Org block.)

> If you want a macro, you could have:
>
> #+BEGIN_SRC: emacs-lisp
>   (defmacro forty-two ()
>             '(* 6 7))
> #+END_SRC
>
> For what you want, you could have it be:
>
> #+BEGIN_SRC: emacs-lisp
>   (defmacro forty-two ()
>             `,(* 6 7))
> #+END_SRC

But this is _not_ what I want!  What I want is to understand the
difference between just C-M-x'ing these forms and evaluating them in
Org-mode.

> Sam

Regards,

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