From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.devel Subject: Re: summary: lilypond, lambda, and local-eval Date: Fri, 16 Dec 2011 10:16:43 +0100 Organization: Organization?!? Message-ID: <87ehw4511g.fsf@fencepost.gnu.org> References: <87r506uodd.fsf@pobox.com> <87pqfpj7e3.fsf@netris.org> <87aa6skika.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1324027038 8194 80.91.229.12 (16 Dec 2011 09:17:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2011 09:17:18 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Dec 16 10:17:14 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 1RbTuj-0005Yd-C2 for guile-devel@m.gmane.org; Fri, 16 Dec 2011 10:17:13 +0100 Original-Received: from localhost ([::1]:44855 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbTui-0004DH-Ml for guile-devel@m.gmane.org; Fri, 16 Dec 2011 04:17:12 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:42331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbTub-0004D9-KO for guile-devel@gnu.org; Fri, 16 Dec 2011 04:17:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbTuX-0008Gk-8b for guile-devel@gnu.org; Fri, 16 Dec 2011 04:17:05 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:38925) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbTuW-0008Ga-VF for guile-devel@gnu.org; Fri, 16 Dec 2011 04:17:01 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RbTuV-0005Sr-CP for guile-devel@gnu.org; Fri, 16 Dec 2011 10:16:59 +0100 Original-Received: from p508edf03.dip.t-dialin.net ([80.142.223.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Dec 2011 10:16:59 +0100 Original-Received: from dak by p508edf03.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Dec 2011 10:16:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 56 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508edf03.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) Cancel-Lock: sha1:IqBZFOj8Z5jzdRB22u3tjZQA6AA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:13129 Archived-At: Mark H Weaver writes: > 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 :) And I consider this _very_ exciting work in progress. One of the things that the current development line of GCC markets is "compiler plugins". Here GUILE has an opportunity to offer similar functionality in a natural, Scheme-like manner with little complexity exposed to the user of this feature, and apparently not all that much complexity needed to get added to the compiler: it is more a matter of factoring the complexity that has to be there anyway in a proper way. Which actually might make the compiler code easier to understand und modify even if you don't end up using local-eval. Being able to employ this in Lilypond to simplify things would certainly be a nice side benefit, but this has the potential to simplify and facilitate quite more complex scenarios with simple tools. It would be _much_ _much_ simpler to use than GCC plugins. And the better it integrates with the compiler as a whole, the less reason would be there _not_ to use it whenever it might be useful. -- David Kastrup