Re: lexbind ready for merge

[Daniel Colascione]

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?