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: A plea for local-eval in 2.0.4 Date: Sat, 14 Jan 2012 18:20:01 +0100 Message-ID: <8762ge5hha.fsf@fencepost.gnu.org> References: <87aa5s8uli.fsf@netris.org> <8762gg7yco.fsf@fencepost.gnu.org> <8739bj8tem.fsf@netris.org> <87boq777xz.fsf@fencepost.gnu.org> <87pqen6qho.fsf@netris.org> <87r4z264nf.fsf@fencepost.gnu.org> <87ty3y5kdo.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1326561612 5837 80.91.229.12 (14 Jan 2012 17:20:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 14 Jan 2012 17:20:12 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jan 14 18:20:08 2012 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 1Rm7Gx-0007XY-PU for guile-devel@m.gmane.org; Sat, 14 Jan 2012 18:20:07 +0100 Original-Received: from localhost ([::1]:38006 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rm7Gw-0005NU-Rw for guile-devel@m.gmane.org; Sat, 14 Jan 2012 12:20:06 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:60795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rm7Gu-0005MJ-J2 for guile-devel@gnu.org; Sat, 14 Jan 2012 12:20:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rm7Gt-000101-Ba for guile-devel@gnu.org; Sat, 14 Jan 2012 12:20:04 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:34908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rm7Gt-0000zx-9y for guile-devel@gnu.org; Sat, 14 Jan 2012 12:20:03 -0500 Original-Received: from localhost ([127.0.0.1]:44827 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rm7Gs-0001dH-I2; Sat, 14 Jan 2012 12:20:02 -0500 Original-Received: by lola (Postfix, from userid 1000) id A52F0E0D0D; Sat, 14 Jan 2012 18:20:01 +0100 (CET) In-Reply-To: <87ty3y5kdo.fsf@netris.org> (Mark H. Weaver's message of "Sat, 14 Jan 2012 11:17:23 -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:13500 Archived-At: Mark H Weaver writes: > David Kastrup writes: >> within local-eval, what is the return value of calling >> (current-module)? I would expect that it is the same as outside of >> local-eval > > Actually, this is not true. Within `local-eval', (current-module) is > temporarily restored (using dynamic-wind) to the module saved in the > lexical environment. > > This is probably not optimal. Among other things, it breaks the nice > equivalence == (local-eval ' (the-environment)), but > `local-eval' and `local-compile' are based on `eval' and `compile', and > this is what `eval' and `compile' do (for some reason unknown to me). This is likely going to be a problem. One can probably fudge around it with something like (local-eval `(let ((current-environment (lambda () ,(current-environment)))) ... but that does not look like it would really prettify things. >> so that (define x 5) inside of local-eval > > As Andy pointed out, I deliberately restrict the form passed to > `local-eval' (or `local-compile') to be an _expression_. (define x 5) > is not an expression; it is a definition. I explained the reason for > this restriction a few days ago[1] on this list. > >> would _not_ be equivalent to (module-define! (current-module) 'x 5) as >> the first one would take the current module at the-environment time, >> and the second one would take it at local-eval time. Well, use set! amd module-set! then for the example. > Actually, because `local-eval' restores (current-module) to the one > saved in the lexical environment, (module-define! (current-module) 'x > 5) within `local-eval' actually defines the variable within the saved > module, i.e. the module used for lookup if you replace > (the-environment) with a top-level variable reference. Looks awkward. And is not compatible with Guilev1 behavior: guile> (save-module-excursion (lambda () (let ((env (the-environment))) (set-current-module (resolve-module '(none))) (local-eval '(current-module) env)))) # guile> -- David Kastrup