* Why does evaluating a piece of Elisp code seemingly not expand a macro?
@ 2016-01-15 10:08 Marcin Borkowski
2016-01-15 10:57 ` Oleh Krehel
2016-01-15 21:10 ` Samuel W. Flint
0 siblings, 2 replies; 9+ messages in thread
From: Marcin Borkowski @ 2016-01-15 10:08 UTC (permalink / raw)
To: Org-Mode mailing list
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Why does evaluating a piece of Elisp code seemingly not expand a macro? 2016-01-15 10:08 Why does evaluating a piece of Elisp code seemingly not expand a macro? Marcin Borkowski @ 2016-01-15 10:57 ` Oleh Krehel 2016-01-17 22:56 ` Marcin Borkowski 2016-01-15 21:10 ` Samuel W. Flint 1 sibling, 1 reply; 9+ messages in thread From: Oleh Krehel @ 2016-01-15 10:57 UTC (permalink / raw) To: Marcin Borkowski; +Cc: Org-Mode mailing list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why does evaluating a piece of Elisp code seemingly not expand a macro? 2016-01-15 10:57 ` Oleh Krehel @ 2016-01-17 22:56 ` Marcin Borkowski 2016-01-18 13:54 ` Stefan Monnier 0 siblings, 1 reply; 9+ messages in thread From: Marcin Borkowski @ 2016-01-17 22:56 UTC (permalink / raw) To: Oleh Krehel; +Cc: Help Gnu Emacs mailing list, Org-Mode mailing list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why does evaluating a piece of Elisp code seemingly not expand a macro? 2016-01-17 22:56 ` Marcin Borkowski @ 2016-01-18 13:54 ` Stefan Monnier 2016-01-18 20:03 ` Marcin Borkowski 0 siblings, 1 reply; 9+ messages in thread From: Stefan Monnier @ 2016-01-18 13:54 UTC (permalink / raw) To: help-gnu-emacs; +Cc: emacs-orgmode > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why does evaluating a piece of Elisp code seemingly not expand a macro? 2016-01-18 13:54 ` Stefan Monnier @ 2016-01-18 20:03 ` Marcin Borkowski 2016-01-18 20:19 ` Stefan Monnier 0 siblings, 1 reply; 9+ messages in thread From: Marcin Borkowski @ 2016-01-18 20:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: help-gnu-emacs, emacs-orgmode 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why does evaluating a piece of Elisp code seemingly not expand a macro? 2016-01-18 20:03 ` Marcin Borkowski @ 2016-01-18 20:19 ` Stefan Monnier 0 siblings, 0 replies; 9+ messages in thread From: Stefan Monnier @ 2016-01-18 20:19 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs, emacs-orgmode > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why does evaluating a piece of Elisp code seemingly not expand a macro? 2016-01-15 10:08 Why does evaluating a piece of Elisp code seemingly not expand a macro? Marcin Borkowski 2016-01-15 10:57 ` Oleh Krehel @ 2016-01-15 21:10 ` Samuel W. Flint 2016-01-15 22:06 ` Nick Dokos 2016-01-15 22:24 ` Marcin Borkowski 1 sibling, 2 replies; 9+ messages in thread From: Samuel W. Flint @ 2016-01-15 21:10 UTC (permalink / raw) To: Marcin Borkowski; +Cc: Org-Mode mailing list [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why does evaluating a piece of Elisp code seemingly not expand a macro? 2016-01-15 21:10 ` Samuel W. Flint @ 2016-01-15 22:06 ` Nick Dokos 2016-01-15 22:24 ` Marcin Borkowski 1 sibling, 0 replies; 9+ messages in thread From: Nick Dokos @ 2016-01-15 22:06 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why does evaluating a piece of Elisp code seemingly not expand a macro? 2016-01-15 21:10 ` Samuel W. Flint 2016-01-15 22:06 ` Nick Dokos @ 2016-01-15 22:24 ` Marcin Borkowski 1 sibling, 0 replies; 9+ messages in thread From: Marcin Borkowski @ 2016-01-15 22:24 UTC (permalink / raw) To: Samuel W. Flint; +Cc: Org-Mode mailing list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-01-18 20:19 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-15 10:08 Why does evaluating a piece of Elisp code seemingly not expand a macro? Marcin Borkowski 2016-01-15 10:57 ` Oleh Krehel 2016-01-17 22:56 ` Marcin Borkowski 2016-01-18 13:54 ` Stefan Monnier 2016-01-18 20:03 ` Marcin Borkowski 2016-01-18 20:19 ` Stefan Monnier 2016-01-15 21:10 ` Samuel W. Flint 2016-01-15 22:06 ` Nick Dokos 2016-01-15 22:24 ` Marcin Borkowski
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).