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: Anything better for delayed lexical evaluation than (lambda () ...)? Date: Wed, 14 Dec 2011 00:16:10 +0100 Message-ID: <878vmgcbb9.fsf@fencepost.gnu.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 1323818183 13955 80.91.229.12 (13 Dec 2011 23:16:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Dec 2011 23:16:23 +0000 (UTC) Cc: Andy Wingo , Mark H Weaver , guile-devel@gnu.org To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Dec 14 00:16:18 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 1Raba5-0007iT-Rw for guile-devel@m.gmane.org; Wed, 14 Dec 2011 00:16:18 +0100 Original-Received: from localhost ([::1]:39327 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Raba4-0005F6-Ef for guile-devel@m.gmane.org; Tue, 13 Dec 2011 18:16:16 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:33221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Raba2-0005Dc-EL for guile-devel@gnu.org; Tue, 13 Dec 2011 18:16:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Raba1-0001SW-GV for guile-devel@gnu.org; Tue, 13 Dec 2011 18:16:14 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:56199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Raba1-0001SS-Da for guile-devel@gnu.org; Tue, 13 Dec 2011 18:16:13 -0500 Original-Received: from localhost ([127.0.0.1]:37884 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Raba0-000547-Iy; Tue, 13 Dec 2011 18:16:13 -0500 Original-Received: by lola (Postfix, from userid 1000) id 304C6E5092; Wed, 14 Dec 2011 00:16:11 +0100 (CET) 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: 140.186.70.10 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:13069 Archived-At: Noah Lavine writes: > 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? guile> '#{ \relative c' { $p 2 \mark #4 } #} (# parser " \\relative c' { $p 2 \\mark #4 } " #f 2 (list (cons 17 (lambda () p)))) In this case, $p is placed into a lambda together with its offset in the string. The whole thing is a function call to a procedure that clones the current parser and let's it parse the enclosed string. Filename and line are just tracked for providing useful error messages. #4 is not turned into a lambda since it is an obvious constant. The obvious wishlist item would be to replace the potentially long and expensive to create argument "closures" (which needs to get consed together on each call since (lambda () p) needs to be created in the current environment) with (package-environment). I have no reliable idea what "memoize" means exactly in Guile's terminology, and the parts of the manual I have consulted have no qualms using this expression, but don't bother explaining it. -- David Kastrup