From: "Pascal J. Bourguignon" <pjb@informatimago.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Lexical binding and macros.
Date: Wed, 15 Dec 2010 18:37:12 +0100 [thread overview]
Message-ID: <87tyifx7hz.fsf@kuiper.lan.informatimago.com> (raw)
In-Reply-To: 87vd2v8107.fsf@lola.goethe.zz
David Kastrup <dak@gnu.org> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> Do they still leak memory? From http://c2.com/cgi/wiki?EmacsLisp :
>>
>>> "Note that variables bound with lexical-let are never released, even
>>> if they are never used. Try
>>
>>> (loop for i from 1 to 100000 collect (lexical-let ((x i)) '()))
>>
>>> and watch it eat memory. So making infinity (ZeroOneInfinity) lexical
>>> variables is out of the question except for very small values of
>>> infinity."
>>
>> Additionally to what Pascal already explained, I'll add that,
>> lexical-let, like `loop' are relatively heavy macros, so you definitely
>> don't want to run them interpreted (where the macro is re-expanded each
>> time).
>
> Why would they be reexpanded each time? They are macros. Their
> expansion is done once and merely evalled each time.
>
> Or do I misunderstand something here?
In the case of Common Lisp, implementations providing an interpreter are
allowed to macro expand everytime. Most implementations do cache the
expansion however. (A lot of CL implementations just compile everything
automatically anyways).
For example, clisp performs the macroexpansions when defining the
function, and one time again when compiling it:
CL-USER> (defmacro m (x)
(format t "(m ~S) is expanded" x)
`(list ',x ',x))
M
CL-USER> (defun f ()
(m 1))
(m 1) is expanded
F
CL-USER> (list (f) (f) (f))
((1 1) (1 1) (1 1))
CL-USER> (compile 'f)
(m 1) is expanded
F
NIL
NIL
CL-USER>
In the case of emacs 23.2.1,
(defmacro m (x)
(message "(m %S) is expanded" x)
`(list ',x ',x))
(defun f ()
(m 1))
(list (f) (f) (f)) --> ((1 1) (1 1) (1 1))
produces in *Messages*:
(m 1) is expanded [3 times]
So it looks like the emacs lisp interpreter doesn't not cache the macro
expansions.
emacs lisp expands it once more when compiling the function too:
(byte-compile 'f) --> #[nil "\300\211D\207" [1] 2]
*Messages*: (m 1) is expanded
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
next prev parent reply other threads:[~2010-12-15 17:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.40.1292017369.4804.help-gnu-emacs@gnu.org>
2010-12-12 4:10 ` Lexical binding and macros Barry Margolin
2010-12-12 17:14 ` LanX
2010-12-12 17:23 ` Pascal J. Bourguignon
2010-12-15 4:24 ` Stefan Monnier
2010-12-15 9:15 ` Elena
2010-12-15 12:38 ` Pascal J. Bourguignon
2010-12-15 15:40 ` Stefan Monnier
2010-12-15 16:16 ` David Kastrup
2010-12-15 17:37 ` Pascal J. Bourguignon [this message]
2010-12-15 17:54 ` Elena
2010-12-16 21:59 ` Stefan Monnier
2010-12-10 21:42 Alin Soare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tyifx7hz.fsf@kuiper.lan.informatimago.com \
--to=pjb@informatimago.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.