all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* compiler macros without byte-compilation
@ 2015-03-20  9:44 Nicolas Richard
  2015-03-20 13:42 ` Stefan Monnier
  0 siblings, 1 reply; 2+ messages in thread
From: Nicolas Richard @ 2015-03-20  9:44 UTC (permalink / raw)
  To: help-gnu-emacs

Hello,

Consider the following:
(progn
  (defun foobar ()
    (declare (compiler-macro
              (lambda (arg)
                "compiler-macro")))
    (message "Done !"))
  (list (symbol-function 'foobar)
        (foobar)))
hit C-x C-e :
 => ((lambda nil (message "Done !")) "compiler-macro")

Now I'm puzzled : why does this happen ? foobar wasn't compiled here !

Looking at readevalloop in lread.c, I thought it was maybe because of
eager macro expansion [which the manual only mentions as happenning at
load time], and in particular I tried changing (symbol-function
'internal-macroexpand-for-load), but that doens't seem to have any
influence on the above behaviour:

(cl-letf (((symbol-function 'internal-macroexpand-for-load) nil))
  (progn
    (defun foobar ()
      (declare (compiler-macro
                (lambda (arg)
                  "compiler-macro")))
      (message "Done !"))
    (list (symbol-function 'foobar)
          (foobar))))
 => ((lambda nil (message "Done !")) "compiler-macro")

Could someone shed some light on this ?

-- 
Nicolas Richard



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: compiler macros without byte-compilation
  2015-03-20  9:44 compiler macros without byte-compilation Nicolas Richard
@ 2015-03-20 13:42 ` Stefan Monnier
  0 siblings, 0 replies; 2+ messages in thread
From: Stefan Monnier @ 2015-03-20 13:42 UTC (permalink / raw)
  To: help-gnu-emacs

>  => ((lambda nil (message "Done !")) "compiler-macro")
> Now I'm puzzled : why does this happen ? foobar wasn't compiled here !

The exact cases where compiler-macros are used are unspecified and
likely to change between versions.

If you want to know the details: compiler-macros are expanded by
macroexpand-all.  So everytime we rely on macroexpand-all (i.e. "eager"
expansion) rather than on macroexpand (i.e. "lazy" expansion), compiler
macros will be expanded.

"Lazy" macroexpansion is on the way out: `eval' does not call
macroexpand-all (because it can happen that `eval' is called repeatedly
in a tight loop to evaluate very short code sequences, where going
through macroexpand-all might be detrimental for performance), but
pretty much all other paths to `eval' do or should (i.e. `load',
`eval-region', ...).


        Stefan




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-03-20 13:42 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-20  9:44 compiler macros without byte-compilation Nicolas Richard
2015-03-20 13:42 ` Stefan Monnier

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.