From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: Elisp lexical-let Date: Thu, 23 Jul 2009 22:56:38 +0200 Message-ID: References: <4A661B73.4090706@domob.eu> <4A66D7BF.5060606@domob.eu> <4A683FB9.50806@domob.eu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1248383411 3976 80.91.229.12 (23 Jul 2009 21:10:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jul 2009 21:10:11 +0000 (UTC) Cc: Ken Raeburn , guile-devel , Neil Jerram To: Daniel Kraft Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jul 23 23:10:03 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MU5Y5-0000uX-Nn for guile-devel@m.gmane.org; Thu, 23 Jul 2009 23:09:58 +0200 Original-Received: from localhost ([127.0.0.1]:54098 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU5Y5-0004BI-4Y for guile-devel@m.gmane.org; Thu, 23 Jul 2009 17:09:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MU5Xt-00047Z-0M for guile-devel@gnu.org; Thu, 23 Jul 2009 17:09:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MU5Xo-00043k-A1 for guile-devel@gnu.org; Thu, 23 Jul 2009 17:09:44 -0400 Original-Received: from [199.232.76.173] (port=51902 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU5Xo-00043e-0w for guile-devel@gnu.org; Thu, 23 Jul 2009 17:09:40 -0400 Original-Received: from a-sasl-quonix.sasl.smtp.pobox.com ([208.72.237.25]:61840 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MU5Xn-0001oZ-FF for guile-devel@gnu.org; Thu, 23 Jul 2009 17:09:39 -0400 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 4016A11FC2; Thu, 23 Jul 2009 17:09:39 -0400 (EDT) Original-Received: from unquote (unknown [81.38.186.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 30DF011FC1; Thu, 23 Jul 2009 17:09:30 -0400 (EDT) In-Reply-To: <4A683FB9.50806@domob.eu> (Daniel Kraft's message of "Thu, 23 Jul 2009 12:47:21 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: 222493BA-77CD-11DE-8237-F699A5B33865-02397024!a-sasl-quonix.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8932 Archived-At: Hi, On Thu 23 Jul 2009 12:47, Daniel Kraft writes: > Ken Raeburn wrote: >> On Jul 22, 2009, at 05:11, Daniel Kraft wrote: >>> It seemed really hard to me to find at least *basic* information >>> about how the lexbind things works; I did build now an emacs with >>> lexbind from trunk, but so far as I see this is not meant to >>> implement "lexical-let" as the cl package does, but rather allows >>> switching all bindings from dynamic to lexical within one source >>> file. >> >> Oh... I may have seriously misunderstood; sorry about that. That's >> what comes from not having bothered to look. :-) > > Ok, I think I'll work on a cl like lexical-let now and see what this > gives in performance related to dynamic let (and just to get it > available of course). > > The implementation will (for now at least) be as I favour it, that is, > inner lets revert to dynamic binding (as do inner lambdas for their > arguments) -- this is more reasonable (I think), has more power (as the > other way can be achieved by using lexical-let for inner lets when > preferred, which is also clearer to understand) and should be easier to > implement (because I don't need to mess around with the compilation of > let constructs depending on the context). Fair enough. The other semantics sound pretty crazy. > I'll keep in mind also the lexbind idea of optionally making every > binding lexical. Andy, can you give me a hint/example/pointer how > compiler options work? This would be exactly the place to provide this, > I think. Additionally we could add an option to remove the "variable is > void" error check for a further performance gain. They don't work! Well, basically they're just a value that reaches the compiler somehow. I think they are a keyword list: (#:foo bar #:baz qux) etc. They are set via the #:opts argument to compile; I don't know if you can set them from the command line. I was waiting for a use case :) Peace, Andy -- http://wingolog.org/