From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Kraft Newsgroups: gmane.lisp.guile.devel Subject: Re: Elisp lexical-let Date: Fri, 24 Jul 2009 09:08:17 +0200 Message-ID: <4A695DE1.4010500@domob.eu> References: <4A661B73.4090706@domob.eu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248419404 14624 80.91.229.12 (24 Jul 2009 07:10:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jul 2009 07:10:04 +0000 (UTC) Cc: Ken Raeburn , guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jul 24 09:09:56 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 1MUEsp-0001sp-EB for guile-devel@m.gmane.org; Fri, 24 Jul 2009 09:07:59 +0200 Original-Received: from localhost ([127.0.0.1]:56188 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUEso-0002b4-Tf for guile-devel@m.gmane.org; Fri, 24 Jul 2009 03:07:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MUEsk-0002Z4-UY for guile-devel@gnu.org; Fri, 24 Jul 2009 03:07:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MUEsg-0002Vh-4F for guile-devel@gnu.org; Fri, 24 Jul 2009 03:07:54 -0400 Original-Received: from [199.232.76.173] (port=45690 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUEsf-0002VX-VP for guile-devel@gnu.org; Fri, 24 Jul 2009 03:07:50 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:35943) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MUEsf-0000km-HM for guile-devel@gnu.org; Fri, 24 Jul 2009 03:07:49 -0400 Original-Received: from taro.utanet.at ([213.90.36.45]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MUEse-0001Sg-Sx for guile-devel@gnu.org; Fri, 24 Jul 2009 03:07:49 -0400 Original-Received: from plenty.xoc.tele2net.at ([213.90.36.8]) by taro.utanet.at with esmtp (Exim 4.69) (envelope-from ) id 1MUEsd-0000KR-Ir; Fri, 24 Jul 2009 09:07:47 +0200 Original-Received: from d83-187-186-129.cust.tele2.at ([83.187.186.129] helo=[192.168.1.18]) by plenty.xoc.tele2net.at with esmtpa (Exim 4.69) (envelope-from ) id 1MUEsd-0004sW-Ey; Fri, 24 Jul 2009 09:07:47 +0200 User-Agent: Thunderbird 2.0.0.0 (X11/20070425) In-Reply-To: X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:8960 Archived-At: Hi Andy, thanks for the clarifications! > It's actually fairly simple, imo. Alpha-equivalence says that > (lexical-let ((x a)) x) is the same as (lexical-let ((y a)) y). (Note > that this lexical-let corresponds to Scheme's let.) So your program is > the same as: > >> (lexical-let ((y 2)) >> y ; -> 2 >> (foo) ; -> 1 >> (setq y 3) >> y ; -> 3 >> (foo) ; -> 1 >> (let ((x 4)) >> x ; -> 4? >> (foo) ; -> 4 >> (setq x 5) >> x ; -> 5 >> (foo) ; -> 5 >> ) ; end the let >> y ; -> 3? >> (foo) ; -> 4 >> ) >> x ; -> 4 >> (foo) ; -> 4 Yes of course, my main question was how the inner let is handled, and what dynamic values x will attain (the results of (foo)) -- and here's this funny stuff that the inner let will be like lexical-let for those variables already lexically bound. > I haven't reviewed your compiler yet, and for that I apologize. But. You > need to make sure that when you compile, you build up a compile-time > environment, mapping symbols to locations -- if a variable is free, > lexically bound, or dynamically bound. When your compiler sees a lexical > binding, replace that identifier with a gensym, and add an entry to your > compile-time environment to map that identifier to that lexical gensym. > That way you will effectively be processing my example, which is > equivalent to yours, but perhaps clearer because the names have been > uniquified. Then your problems go away. This is how I was thinking about implementing the lexical-let semantics. To give more details: I want to keep track of identifiers that are lexically bound in the current scope while compiling as well as to what gensym they are, and then instead of the fluid-ref's just reference/set this gensym-identifier when I come across an access. It seems this is exactly what you describe above :) So, that's it with regards to messages from me :D Thanks for all your comments again, Daniel -- Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz To go: Hea-Kni-Mon-Pri