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 09:16:09 +0100 Message-ID: <87r507bmba.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> <87borc9h3a.fsf@pobox.com> <87k460ngf3.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1323850582 25482 80.91.229.12 (14 Dec 2011 08:16:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Dec 2011 08:16:22 +0000 (UTC) Cc: Andy Wingo , guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Dec 14 09: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 1Rak0e-0008Js-IJ for guile-devel@m.gmane.org; Wed, 14 Dec 2011 09:16:16 +0100 Original-Received: from localhost ([::1]:45569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rak0e-0004UU-1Q for guile-devel@m.gmane.org; Wed, 14 Dec 2011 03:16:16 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:55623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rak0b-0004Qk-GA for guile-devel@gnu.org; Wed, 14 Dec 2011 03:16:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rak0Z-0001H4-VE for guile-devel@gnu.org; Wed, 14 Dec 2011 03:16:13 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:35978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rak0Z-0001H0-SL for guile-devel@gnu.org; Wed, 14 Dec 2011 03:16:11 -0500 Original-Received: from localhost ([127.0.0.1]:45897 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rak0Y-00020c-OS; Wed, 14 Dec 2011 03:16:11 -0500 Original-Received: by lola (Postfix, from userid 1000) id 87705E5092; Wed, 14 Dec 2011 09:16:09 +0100 (CET) In-Reply-To: <87k460ngf3.fsf@netris.org> (Mark H. Weaver's message of "Tue, 13 Dec 2011 19:30:24 -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:13079 Archived-At: Mark H Weaver writes: > Andy Wingo writes: >> On Wed 14 Dec 2011 00:00, Noah Lavine writes: >>> 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.... >> >> The details of the interpreter's implementation are not public, I'm >> afraid. The interpreter does its job, but not quickly, and any change >> to make it better would involve a change to the environment >> representation. > > I agree that the returned "lexical environment object" should opaque. > Probably the only operation that needs this object is "local-eval", > though I'm not sure there's any disadvantage to printing it in > human-readable form for debugging purposes. I was actually somewhat surprised that one could not just use "eval" here and give it the environment instead of a module argument. It is not actually obvious from the documentation whether the active module is part of the environment or not. To be fair, not much is obvious from the documentation of local-eval (documented in Guile 1.8, one occurence of "memoized" in this version). @c snarfed from debug.c:406 @deffn {Scheme Procedure} local-eval exp [env] @deffnx {C Function} scm_local_eval (exp, env) Evaluate @var{exp} in its environment. If @var{env} is supplied, it is the environment in which to evaluate @var{exp}. Otherwise, @var{exp} must be a memoized code object (in which case, its environment is implicit). @end deffn >> Anyway, it's looking in the wrong place. There is a compiler too. > > The most obvious implementation of (capture-lexical-environment) would > inhibit compilation of any top-level form that contains it. Well, it probably is less invasive than the equivalent of marking every local variable (similarly to global ones) as subject to change across calls. > Therefore, the only thing the compiler would need to do is detect the > presence of (capture-lexical-environment), and in that case, abort > compilation of the entire top-level form. I guess such a form should > be "compiled" simply as a call to the evaluator with the entire > top-level form as its argument. This would all happen after macro > expansion, of course. > > Does this make sense? Sounds a bit heavy-handed. For the use cases in Lilypond, I don't expect noticeable slow-downs as long as "the evaluator" works with reasonable performance for an interpreter and is not coded with the "we have a compiler anyway, so this will only run in exceptional cases and can be exceptionally slow" frame of mind. But it does a reasonably simple job, and probably is not significantly changed from Guile v1, so I don't expect much of a problem here. So this would basically work for Lilypond. It would, however, be likely a good idea to have it in a state where attaching strong-worded warnings to the documentation is not necessary. Something like "If an environment is being captured, the enclosing code can't be optimized (in the current implementation, it is simply left uncompiled). So it is a good idea to place performance-critical code in functions separate from those where you need to capture the environment." should likely be enough. -- David Kastrup