From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: Anything better for delayed lexical evaluation than (lambda () ...)? Date: Tue, 13 Dec 2011 18:00:13 -0500 Message-ID: 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> <87mxaxihnw.fsf@pobox.com> <87obvclu92.fsf@fencepost.gnu.org> <87aa6wbp0w.fsf@pobox.com> <87fwgolgm5.fsf@fencepost.gnu.org> <8762hkbkwi.fsf@pobox.com> <87borclcem.fsf@fencepost.gnu.org> <87zkewa2vy.fsf@pobox.com> <87zkewjvyz.fsf@fencepost.gnu.org> <87vcpka13n.fsf@pobox.com> <87zkewnzy7.fsf@netris.org> <87r5089ui3.fsf@pobox.com> <87r508nv0o.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1323817236 7408 80.91.229.12 (13 Dec 2011 23:00:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Dec 2011 23:00:36 +0000 (UTC) Cc: Andy Wingo , David Kastrup , guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Dec 14 00:00:27 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 1RabKh-0000yQ-DT for guile-devel@m.gmane.org; Wed, 14 Dec 2011 00:00:23 +0100 Original-Received: from localhost ([::1]:50893 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RabKh-0001F7-2b for guile-devel@m.gmane.org; Tue, 13 Dec 2011 18:00:23 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:46785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RabKd-0001Ew-9z for guile-devel@gnu.org; Tue, 13 Dec 2011 18:00:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RabKc-0006cf-4R for guile-devel@gnu.org; Tue, 13 Dec 2011 18:00:19 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:59496) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RabKa-0006cC-0L; Tue, 13 Dec 2011 18:00:16 -0500 Original-Received: by iahk25 with SMTP id k25so277248iah.0 for ; Tue, 13 Dec 2011 15:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/4teGO3Z0hD6tMiWuDHm0V6c/SWO/Io5ZUWqsQOGSmk=; b=T96wlbxeEYxZpDz3yx99er1oEAIat/mtq6zdm7RhxlSKDZBs9euIjW1QhNsrF1SQQ8 BDuIhnBqQ1eucEVOkhvIUlkvhTzQqpDxsvRSO7IXO53HNIHN4kjsXBNOtgUZv2AXL5or 4b7W+c8iUh9Gjp83TTha43lbZiWCimFglh25A= Original-Received: by 10.50.161.162 with SMTP id xt2mr20948044igb.72.1323817213788; Tue, 13 Dec 2011 15:00:13 -0800 (PST) Original-Received: by 10.42.217.6 with HTTP; Tue, 13 Dec 2011 15:00:13 -0800 (PST) In-Reply-To: <87r508nv0o.fsf@netris.org> X-Google-Sender-Auth: MhsWNB7B1xP21HineZm-uE3WDBc X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 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:13068 Archived-At: Hello, I haven't really been contributing to this thread, so please take my opinion with a grain of salt. But it does appear to me that we should support capturing a lexical environment, as Mark and David describe. So I took a look at ice-9/eval.scm to see how difficult it would be to implement. Offhand, it doesn't look bad: the eval function there already passes around environment objects, so if it hit this special form, it would simply return its environment object (probably packaged up in a record so it would print nicely). Restarting it is also simple: call eval on an expression with the given environment. The environment objects already contain all of the information needed to evaluate expressions, so I don't think there is very much to do there. The part that seems more interesting to me is that Guile's evaluator attempts to memoize an entire expression before evaluating any of it, which I understand is impossible with Lilypond. I assume Lilypond handles this by bundling the Lilypond code into a string (or some other object), letting the memoizer look at that, and then later doing the actual expansion. David, is this how you handle that? Noah On Tue, Dec 13, 2011 at 2:15 PM, Mark H Weaver wrote: > Andy Wingo writes: >> On Tue 13 Dec 2011 18:28, Mark H Weaver writes: >> >>> >> (let ((xxx 2)) >>> >> =A0 #{ #(set! xxx (1+ xxx)) #}) >> >>> In the general case, Lilypond needs to _execute_ the outer Scheme code >>> before the parser/evaluator is able to even _see_ the inner Scheme code= , >>> because it needs to parse/evaluate the Lily code in between the two, an= d >>> we've already established that parsing cannot be not be done without >>> runtime information. >> >> What does it mean to execute a `(let ((xxx 2))' ? =A0I think I need to >> read the thread again, because I am really not getting it. > > Well, this example is a bit too simple to illustrate the point. > Let's consider a slightly more complex example: > > =A0(let ((xxx (foobar 1 2))) > =A0 =A0#{ #(begin (set! xxx (1+ xxx)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 (let ((yyy (foobar 3 4))) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #{ #(set! yyy (+ xxx yyy)) #} )) #} ) > > In this case, Lilypond would need to start by evaluating: > > =A0(let ((xxx (foobar 1 2))) > =A0 =A0 (capture-lexical-environment)) > > which entails evaluating (foobar 1 2), extending the lexical environment > with a binding for "xxx", and then returning a new lexical environment > object. > > Then Lilypond would then continue to parse/evaluate the Lilypond code > beginning with #{, which in the general case must be done at the same > time as execution. =A0When it finds the #( it enters Scheme mode again, > so it would then pass the lexical environment object from the previous > step to "local-eval" with the following expression: > > =A0(begin (set! xxx (1+ xxx)) > =A0 =A0 =A0 =A0 (let ((yyy (foobar 3 4))) > =A0 =A0 =A0 =A0 =A0 (capture-lexical-environment))) > > which entails mutating "xxx", evaluating (foobar 3 4) and extending the > lexical environment again (which should now contain both xxx and yyy), > and then returning a new lexical environment object. =A0And so on. > > Does this make sense? > >>> How difficult would it be to implement this? >> >> Dunno. =A0I was thinking that we could have a special form to return a >> list of the identifiers in scope. > > I don't think this is sufficient. =A0The special form must return a > lexical environment object that contains everything needed by a > "local-eval" procedure (which we should also provide) to evaluate > arbitrary scheme code within that lexical environment. > > The key is that we must create the lexical environment object before we > know anything about the code that will later be passed to "local-eval". > > =A0 =A0Thanks, > =A0 =A0 =A0Mark >