all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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?



  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

* 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 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.