From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Hans Aberg Newsgroups: gmane.lisp.guile.devel Subject: Re: summary: lilypond, lambda, and local-eval Date: Fri, 16 Dec 2011 15:57:26 +0100 Message-ID: References: <87r506uodd.fsf@pobox.com> <87pqfpj7e3.fsf@netris.org> <87liqcamrf.fsf@pobox.com> <871us4kdqy.fsf@netris.org> <87k45w3cwz.fsf@fencepost.gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1324047474 25202 80.91.229.12 (16 Dec 2011 14:57:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2011 14:57:54 +0000 (UTC) Cc: guile-devel@gnu.org To: David Kastrup Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Dec 16 15:57:49 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 1RbZEF-0004hD-Mb for guile-devel@m.gmane.org; Fri, 16 Dec 2011 15:57:43 +0100 Original-Received: from localhost ([::1]:52275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZEF-0004ss-9B for guile-devel@m.gmane.org; Fri, 16 Dec 2011 09:57:43 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:59505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZE9-0004sZ-4q for guile-devel@gnu.org; Fri, 16 Dec 2011 09:57:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbZE3-0005dC-D7 for guile-devel@gnu.org; Fri, 16 Dec 2011 09:57:37 -0500 Original-Received: from smtp-out21.han.skanova.net ([195.67.226.208]:55986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZDz-0005cd-Ev; Fri, 16 Dec 2011 09:57:27 -0500 Original-Received: from [10.0.1.2] (217.210.127.13) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u26619196) id 4EC0B93A00D602DF; Fri, 16 Dec 2011 15:57:25 +0100 In-Reply-To: <87k45w3cwz.fsf@fencepost.gnu.org> X-Mailer: Apple Mail (2.1251.1) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 195.67.226.208 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:13141 Archived-At: On 16 Dec 2011, at 13:43, David Kastrup wrote: >>> Here's what I currently see: >>>=20 >>> scheme@(guile-user)> (local-eval #'t (primitive-eval '(let ((t 42)) >>> (or #f (the-environment))))) >>> ERROR: In procedure memoize-variable-access!: >>> ERROR: Unbound variable: t >>>=20 >>> This is the correct behavior, no? >>=20 >> This is what I get when I play around with the following variation of = David's code in Guile 2.0.3: >> (define (xxx) >> (let* ((x 2)) >> (set! x (+ x 3)) >> (interaction-environment))) >>=20 >> (eval '(begin (set! x (+ x 5)) x) (xxx)) >>=20 >> My guess (correct?) is that one wants some variation of >> (interaction-environment) that can cause x in the eval expression to >> bind to the environment returned by (xxx). >>=20 >> Might eval be changed to accommodate for that (without introducing = the >> name local-eval)? >=20 > It would likely help with unasking the question of what to do when > (current-module) is different at the time of local-eval. I don't = know, > however, what the _lexical_ effects of switching the current module = are > supposed to be. If it is supposed to be a noop, then lexical > environments and modules are presumably orthogonal, and eval should > likely be allowed to take both (currently, local-eval is like taking a > lexical environment and using primitive-eval in it). Would you not it work as though you inserted code in the place where = then environment? - Then the syntactical rules should be captured as = well. In addition, there should be a way to communicate with the surrounding = environment, wherefrom the code is inserted. The only truly safe way = would be to make that explicit somehow, if not merely returning a value = suffices. Hans