From: Daniel Colascione <dan.colascione@gmail.com>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: lexbind ready for merge
Date: Tue, 29 Mar 2011 16:43:37 -0700 [thread overview]
Message-ID: <4D926EA9.5080509@gmail.com> (raw)
In-Reply-To: <jwvbp0t61xm.fsf-monnier+emacs@gnu.org>
On 3/29/2011 2:44 PM, Stefan Monnier wrote:
> OK, so AFAIK the lexbind branch is pretty much ready for merge.
> The only issue is that I'm not sure it has seen as much testing as
> I'd like, but then that's largely because it hasn't been merged yet.
> So if I don't hear any screams until then, I plan to merge it into trunk
> over the week-end or nearby.
Thanks. I've been looking forward to this for a while.
Just a few comments (I might send patches for some of these things when
I have time):
- The elisp manual still claims in a variety of places that Emacs does
not support closures
- apply-partially should have a compiler-macro now that we can implement
it very efficiently; also, funcall-partially.
- It might be a good idea to remove the "Once Emacs 19 becomes
standard..." comment from cl.el
- Can lexical-let and lexical-let* be made a no-op when compiling
lexbound code? Looking at cl.el, it appears they're still up their
usual dirty tricks.
- lexical-binding only applies to code evaluated by `eval-buffer' and
`eval-region'?! So I can't make code evaluated by M-: lexbound?
- It'd be nice to be able to write small pieces of lexical code in
non-lexbound code, e.g., in the expansion of a macro that gets used by
both lexbound and non-lexbound. What's the best way to do that?
- The documentation claims that defun doesn't capture its lexical scope.
In interpreted code, it does.
(require 'cl)
(let ((bar2 5))
(defun foo ()
(incf bar2)
(message "hi: %s" bar2)))
In compiled code, we do not capture the variable and instead warn about
it. Instead, we should capture the variable. Common Lisp explicitly
allows this use, and it's convenient in some cases.
- Disassembling a closure reports closed-over variables as constants;
they're not.
- Do we really use a whole cons cell for each closed-over variable, even
in compiled code?
next prev parent reply other threads:[~2011-03-29 23:43 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-29 21:44 lexbind ready for merge Stefan Monnier
2011-03-29 23:43 ` Daniel Colascione [this message]
2011-03-30 1:22 ` Stefan Monnier
2011-03-30 4:10 ` Daniel Colascione
2011-03-30 11:35 ` Juanma Barranquero
2011-03-30 13:24 ` lexbind: how to replace lexical-let approach to hide secrets (was: lexbind ready for merge) Ted Zlatanov
2011-03-30 21:12 ` lexbind: how to replace lexical-let approach to hide secrets Stefan Monnier
2011-03-30 21:56 ` David Kastrup
2011-03-30 22:29 ` Daniel Colascione
2011-03-31 15:42 ` Ted Zlatanov
2011-04-01 1:31 ` Stephen J. Turnbull
2011-04-01 4:41 ` secret strings (was: lexbind: how to replace lexical-let approach to hide secrets) Ted Zlatanov
2011-04-01 5:52 ` Stephen J. Turnbull
2011-04-01 11:02 ` secret strings Ted Zlatanov
2011-04-01 14:38 ` Stephen J. Turnbull
2011-04-01 15:12 ` Ted Zlatanov
2011-04-01 16:14 ` Stephen J. Turnbull
2011-04-01 20:08 ` Ted Zlatanov
2011-04-01 20:34 ` Stefan Monnier
2011-04-01 21:25 ` Ted Zlatanov
2011-04-01 14:59 ` Stefan Monnier
2011-03-30 15:09 ` lexbind ready for merge Daniel Colascione
2011-03-30 15:20 ` Juanma Barranquero
2011-03-30 14:26 ` Stefan Monnier
2011-03-30 7:28 ` Tassilo Horn
2011-03-30 11:30 ` Eli Zaretskii
2011-03-30 13:10 ` Tassilo Horn
2011-03-30 13:17 ` Ted Zlatanov
2011-03-30 14:29 ` Stefan Monnier
2011-03-30 14:54 ` Tassilo Horn
2011-03-31 1:02 ` Stephen J. Turnbull
2011-03-30 16:11 ` Lars Magne Ingebrigtsen
2011-03-30 17:10 ` Tassilo Horn
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D926EA9.5080509@gmail.com \
--to=dan.colascione@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.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).