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: Tue, 13 Dec 2011 20:30:49 -0500 Message-ID: <87fwgondme.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> <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 X-Trace: dough.gmane.org 1323826356 27360 80.91.229.12 (14 Dec 2011 01:32:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Dec 2011 01:32:36 +0000 (UTC) Cc: Andy Wingo , David Kastrup , guile-devel@gnu.org To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Dec 14 02:32:29 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 1Radhs-0008L4-T4 for guile-devel@m.gmane.org; Wed, 14 Dec 2011 02:32:29 +0100 Original-Received: from localhost ([::1]:39658 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Radhs-0004XV-66 for guile-devel@m.gmane.org; Tue, 13 Dec 2011 20:32:28 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:49346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Radhp-0004XM-Nq for guile-devel@gnu.org; Tue, 13 Dec 2011 20:32:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Radho-0005S5-OB for guile-devel@gnu.org; Tue, 13 Dec 2011 20:32:25 -0500 Original-Received: from world.peace.net ([96.39.62.75]:51815) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Radho-0005Rr-FQ; Tue, 13 Dec 2011 20:32:24 -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 1Radhj-0008Gs-0C; Tue, 13 Dec 2011 20:32:19 -0500 In-Reply-To: (Noah Lavine's message of "Tue, 13 Dec 2011 18:00:13 -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:13077 Archived-At: Hi Noah, Noah Lavine writes: > 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 also looked at eval.scm, and I see a complication. The environments passed around in ice-9/eval.scm do not contain any variable names. The evaluator works with memoized expressions, where variable references are replaced by indices into the environment. Therefore, the memoizer would need to be enhanced to support (capture-lexical-environment) specially. The evaluator may not know the variable names, but the memoizer does. After all, one of its jobs is to convert variable references from symbols to indices. The most straightforward solution I see is the following: When the memoizer converts (capture-lexical-environment) into a memoized object, it should embed within that object its own "memoizer environment" (a list of variable names). Then, when the (capture-lexical-environment) is evaluated, it simply bundles together both the memoizer's environment (a list of variable names) and the evaluator's environment (a list of variable values) into an opaque lexical environment object. When "local-eval" is called, it will need to first call the memoizer and then the evaluator. It will have everything it needs to do this within the lexical environment object. What do you think? Best, Mark