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: summary: lilypond, lambda, and local-eval Date: Fri, 16 Dec 2011 03:49:09 -0500 Message-ID: <87aa6skika.fsf@netris.org> References: <87r506uodd.fsf@pobox.com> <87pqfpj7e3.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1324025463 30190 80.91.229.12 (16 Dec 2011 08:51:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2011 08:51:03 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Dec 16 09:50:56 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RbTVI-0003G0-68 for guile-devel@m.gmane.org; Fri, 16 Dec 2011 09:50:56 +0100 Original-Received: from localhost ([::1]:46324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbTVH-0000vd-PY for guile-devel@m.gmane.org; Fri, 16 Dec 2011 03:50:55 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:52848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbTVF-0000vI-4w for guile-devel@gnu.org; Fri, 16 Dec 2011 03:50:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbTV9-000317-JM for guile-devel@gnu.org; Fri, 16 Dec 2011 03:50:53 -0500 Original-Received: from world.peace.net ([96.39.62.75]:59181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbTV9-00030v-6y for guile-devel@gnu.org; Fri, 16 Dec 2011 03:50:47 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1RbTV3-0007ph-Du; Fri, 16 Dec 2011 03:50:41 -0500 In-Reply-To: <87pqfpj7e3.fsf@netris.org> (Mark H. Weaver's message of "Fri, 16 Dec 2011 02:35:48 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:13128 Archived-At: I wrote: > For now, I will describe a method that I suspect would do the right > thing without any new compiler interfaces, though not as efficiently or > robustly: Simply compile the same general-purpose dispatcher as before, > except replace the #f (from the first case-lambda clause) with the > expanded local expression: Although this should result in the same set of captured lexicals, it does not necessarily guarantee that the closure slots will be in the same order. This could be perhaps be solved by always sorting the captured lexicals by name, but that would slow down the compiler. Depending on how the compiler works, it might be sufficient to move the case to end of the case-lambda, but that's definitely fragile. So, I guess this all shows that `local-eval' really shouldn't be implemented this way, but rather by creating a new internal interface to the compiler that ensures that the closure slots are exactly the same as before. > Most passes of the compiler will pretend that (the-environment) is > replaced by tree-il code corresponding to the following standard scheme > code: I should also mention that perhaps, instead of simply "pretending", it might make sense to actually replace (the-environment) with the standard scheme code I gave as early as possible, so that later passes will never even see `the-environment' tree-il nodes. It need only be late enough so that the list of visible lexical variable names is known at that point. Apologies for sending multiple messages so quickly. Obviously this is a work-in-progress :) Mark