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 19:30:24 -0500 Message-ID: <87k460ngf3.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> <87borc9h3a.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1323822730 7643 80.91.229.12 (14 Dec 2011 00:32:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Dec 2011 00:32:10 +0000 (UTC) Cc: David Kastrup , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Dec 14 01:32:06 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 1RaclS-0003kb-Ba for guile-devel@m.gmane.org; Wed, 14 Dec 2011 01:32:06 +0100 Original-Received: from localhost ([::1]:43982 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaclR-0000i3-OK for guile-devel@m.gmane.org; Tue, 13 Dec 2011 19:32:05 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:59720) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaclO-0000hi-LW for guile-devel@gnu.org; Tue, 13 Dec 2011 19:32:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RaclM-0000MV-Mv for guile-devel@gnu.org; Tue, 13 Dec 2011 19:32:02 -0500 Original-Received: from world.peace.net ([96.39.62.75]:39364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaclM-0000MB-Gg; Tue, 13 Dec 2011 19:32:00 -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 1RaclG-00087U-1P; Tue, 13 Dec 2011 19:31:54 -0500 In-Reply-To: <87borc9h3a.fsf@pobox.com> (Andy Wingo's message of "Wed, 14 Dec 2011 00:39:37 +0100") 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:13074 Archived-At: 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. It might also be nice to provide a procedure that converts it into an alist of some sort, but that's not strictly needed. I believe this would give us plenty of freedom to change the environment representation in the future, no? > 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. 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? Mark