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: Anything better for delayed lexical evaluation than (lambda () ...)? Date: Mon, 12 Dec 2011 16:40:03 -0500 Message-ID: <87sjkph3kc.fsf@netris.org> References: <87liqtpsl9.fsf@fencepost.gnu.org> <874nxdwkbi.fsf@rapitore.luna> <87d3bvfo5d.fsf@fencepost.gnu.org> <871usaicvi.fsf@netris.org> <87mxaycmlx.fsf@fencepost.gnu.org> <87wra1hcek.fsf@netris.org> <87liqhbm3u.fsf@fencepost.gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1323726107 20846 80.91.229.12 (12 Dec 2011 21:41:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 12 Dec 2011 21:41:47 +0000 (UTC) Cc: guile-devel@gnu.org To: David Kastrup Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Dec 12 22:41:41 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 1RaDcy-00006E-6l for guile-devel@m.gmane.org; Mon, 12 Dec 2011 22:41:40 +0100 Original-Received: from localhost ([::1]:41309 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaDcx-0000t3-Ej for guile-devel@m.gmane.org; Mon, 12 Dec 2011 16:41:39 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:41215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaDcu-0000rt-Jy for guile-devel@gnu.org; Mon, 12 Dec 2011 16:41:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RaDct-0003wS-JA for guile-devel@gnu.org; Mon, 12 Dec 2011 16:41:36 -0500 Original-Received: from world.peace.net ([96.39.62.75]:47408) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaDct-0003w7-FW; Mon, 12 Dec 2011 16:41:35 -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 1RaDcn-0004Bk-Ob; Mon, 12 Dec 2011 16:41:29 -0500 In-Reply-To: <87liqhbm3u.fsf@fencepost.gnu.org> (David Kastrup's message of "Mon, 12 Dec 2011 20:56:05 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (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:13042 Archived-At: David Kastrup writes: > Very funny. If x is not an integer, it is put into the music argument > instead, and the next "argument" is not an argument but independent > code. Ah, okay. In that case, the design of the Lilypond language does indeed make compilation (or even parsing) before execution absolutely impossible. Oh well. >> You are using Guile in a very unusual way. You have constructed a >> hybrid language of both Scheme and Lilypond, > > That's what "extension language" as opposed to "implementation language" > means. I guess this is the crux of your misunderstanding over what Guile is "supposed to be". Apparently you believe that an "extension language" is one that allows you to mix your own language interpreter with the extension language's interpreter to build a hybrid language that is implemented by both code bases working together. Can you please find a reference to back up your definition of "extension language"? I looked and I couldn't find one that supports your view. For the record, I don't believe that this use of Guile was _ever_ what Guile was intended for. Anyway, it's water under the bridge now. To be fair, some past maintainer of Guile apparently decided to make "procedure-environment" part of the public API -- a very serious error in my view -- and the Lilypond developers made use of this functionality to build their system. I guess the responsibility to make this right ultimately rests on our shoulders, as inheritors of the unwise promises made by our predecessors. In order to make this right, and in general to support languages like Lilypond that cannot even be parsed before execution, I guess we should implement the "capture-lexical-environment" special form, along with a "local-eval" that makes use of it. I guess the most straightforward implementation is to simply inhibit compilation of any top-level form that contains a "capture-lexical-environment" special form. Instead we would use the bootstrap evaluator to execute such top-level forms, and also to implement "local-eval". Andy, this is your area. I'd be willing to work on this, but before I do, can you at least comment on whether you think this is the right approach, and what complications I'm likely to run into along the way? Thanks, Mark