From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: lexbind ready for merge Date: Tue, 29 Mar 2011 21:22:43 -0400 Message-ID: References: <4D926EA9.5080509@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1301448488 8833 80.91.229.12 (30 Mar 2011 01:28:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 30 Mar 2011 01:28:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 30 03:27:56 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4kCS-0007i7-2W for ged-emacs-devel@m.gmane.org; Wed, 30 Mar 2011 03:27:56 +0200 Original-Received: from localhost ([127.0.0.1]:36038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4k7X-0000Vh-A2 for ged-emacs-devel@m.gmane.org; Tue, 29 Mar 2011 21:22:51 -0400 Original-Received: from [140.186.70.92] (port=46696 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4k7S-0000Vc-Ai for emacs-devel@gnu.org; Tue, 29 Mar 2011 21:22:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4k7R-0004TP-2U for emacs-devel@gnu.org; Tue, 29 Mar 2011 21:22:46 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:5423 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4k7Q-0004TK-Uc for emacs-devel@gnu.org; Tue, 29 Mar 2011 21:22:45 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGiFkk1FpZRw/2dsb2JhbAClUHiIebZnhWoElhQ X-IronPort-AV: E=Sophos;i="4.63,266,1299474000"; d="scan'208";a="98596762" Original-Received: from 69-165-148-112.dsl.teksavvy.com (HELO ceviche.home) ([69.165.148.112]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 29 Mar 2011 21:22:43 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 6D09B660C7; Tue, 29 Mar 2011 21:22:43 -0400 (EDT) In-Reply-To: <4D926EA9.5080509@gmail.com> (Daniel Colascione's message of "Tue, 29 Mar 2011 16:43:37 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137884 Archived-At: > - 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 () ) ) 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