Re: lexbind ready for merge

[Stefan Monnier]

> - The elisp manual still claims in a variety of places that Emacs does not
> support closures

Pointers to offenders welcome.

> - apply-partially should have a compiler-macro now that we can implement it
> very efficiently; also, funcall-partially.

The current definition of apply-partially is not too
inefficient, actually.  I don't know what funcall-partially would
be like.  And I don't like either of them: apply-partially is just a way
to make it easy to build closures by hand without resorting to
lexical-let and independently from lexical-binding, but once you use
lexical-binding you're usually better off using a plain closure.

> - It might be a good idea to remove the "Once Emacs 19 becomes standard..."
> comment from cl.el

Feel free to do that on the trunk, I don't think it's really related
to lexbind.

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

They can *almost* be turned into `let' and `let*', except that
(lexical-let ((buffer-file-name 3)) ...) will bind buffer-file-name
lexically whereas `let' will always bind it dynamically.  We could
either ignore those issues or try to handle them, but I'd rather just
mark lexical-let obsolete.
(Of course, there's also the difficulty for the macro to reliably
determine whether the expansion will be run in lexical-binding or
dynamic-binding mode).

> - lexical-binding only applies to code evaluated by `eval-buffer' and
> eval-region'?! So I can't make code evaluated by M-: lexbound?

?!?  AFAIK, M-: uses lexical or dynamic scoping according to the value
of lexical-binding in the current buffer.

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

Yes, it'd be nice.

> What's the best way to do that?

Currently, I think the best way to do that is to add the feature to the
byte-compiler.  The most promising avenue for it might be to use code
of the form ((closure () <formalargs> <lexbindcode>) <actualargs>) and
compile efficiently (I think currently such code will either result in
a complaint about a malformed function, or else will leave the function
uncompiled).

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

Yup.

> Common Lisp explicitly allows this use, and it's convenient in
> some cases.

If you need it you can use

  (let ((bar2 5))
    (defalias 'foo (lambda ()
      "Foo."
      (incf bar2)
      (message "hi: %s" bar2))))

IIRC, the reason why defun doesn't work for it is fundamentally linked
to some silly technicality, but I justify it for myself by the fact that
all the "defun within a non-empty context" I've seen were bogus, so I'm
not strongly motivated to handle it right.

> - Disassembling a closure reports closed-over variables as constants;
> they're not.

They are.

> - Do we really use a whole cons cell for each closed-over variable, even in
> compiled code?

Yes, tho only for variables which are mutated (yup, `setq' is costly).


        Stefan