From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Elisp lexical-let Date: Thu, 23 Jul 2009 12:13:13 -0400 Message-ID: <20090723161313.GA1405@fibril.netris.org> References: <4A661B73.4090706@domob.eu> <4A66D7BF.5060606@domob.eu> <4A670D78.3040804@gentoo.org> <4A67676F.9010905@domob.eu> <4A6880AE.9070600@gentoo.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1248365627 4338 80.91.229.12 (23 Jul 2009 16:13:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jul 2009 16:13:47 +0000 (UTC) Cc: Andy Wingo , Neil Jerram , Daniel Kraft , Ken Raeburn , guile-devel To: "Marijn Schouten (hkBst)" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jul 23 18:13:39 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 1MU0vL-0006qI-2h for guile-devel@m.gmane.org; Thu, 23 Jul 2009 18:13:39 +0200 Original-Received: from localhost ([127.0.0.1]:43357 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU0vK-0006qT-AF for guile-devel@m.gmane.org; Thu, 23 Jul 2009 12:13:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MU0vD-0006p8-IT for guile-devel@gnu.org; Thu, 23 Jul 2009 12:13:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MU0v9-0006lD-5x for guile-devel@gnu.org; Thu, 23 Jul 2009 12:13:31 -0400 Original-Received: from [199.232.76.173] (port=54180 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU0v8-0006l5-TY for guile-devel@gnu.org; Thu, 23 Jul 2009 12:13:26 -0400 Original-Received: from world.peace.net ([204.107.200.8]:54563) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MU0v8-0006MP-L2 for guile-devel@gnu.org; Thu, 23 Jul 2009 12:13:26 -0400 Original-Received: from localhost ([127.0.0.1] helo=fibril.netris.org ident=hope1) by world.peace.net with esmtp (Exim 4.69) (envelope-from ) id 1MU0v0-00050y-5S; Thu, 23 Jul 2009 12:13:18 -0400 Content-Disposition: inline In-Reply-To: <4A6880AE.9070600@gentoo.org> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:8923 Archived-At: On Thu, Jul 23, 2009 at 05:24:30PM +0200, Marijn Schouten (hkBst) wrote: > For the calls above all the dynamic accesses can be determined statically. > Lexical accesses can always be determined statically. Thus all accesses in this > example can be determined statically and can be compiled to a location > dereference (either read or write). Nothing in the semantics is inherently > inefficient. There is at least one inherent loss of efficiency with the semantics you propose: with a lexical-let binding, the compiler can determine statically whether the variable is non-mutable, because the only place it could possibly be set! is within the lexical scope. Non-mutable variables can safely be inlined, an especially important optimization, especially if the value is a procedure. Also, with lexical-let, the compiler knows statically the entire set of references, which can be helpful with many analyses, for example whether continuations or closures can "escape" a particular scope, whether a particular continuation might be invoked more than once, etc. Regards, Mark