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: [PATCH] Implement `the-environment' and `local-eval' in evaluator Date: Fri, 16 Dec 2011 15:26:26 +0100 Organization: Organization?!? Message-ID: <87fwgk384t.fsf@fencepost.gnu.org> References: <87liqtpsl9.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> <87fwgondme.fsf@netris.org> <87borboalb.fsf@netris.org> <877h1zo7xx.fsf_-_@netris.org> <8762hgkh2k.fsf_-_@netris.org> <8762hg50b3.fsf@fencepost.gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1324045623 11191 80.91.229.12 (16 Dec 2011 14:27:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2011 14:27:03 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Dec 16 15:27:00 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 1RbYkV-0007IL-0V for guile-devel@m.gmane.org; Fri, 16 Dec 2011 15:26:59 +0100 Original-Received: from localhost ([::1]:51444 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbYkU-0001Rd-AH for guile-devel@m.gmane.org; Fri, 16 Dec 2011 09:26:58 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:39967) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbYkR-0001RY-C0 for guile-devel@gnu.org; Fri, 16 Dec 2011 09:26:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbYkK-0007p9-Pt for guile-devel@gnu.org; Fri, 16 Dec 2011 09:26:55 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:50699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbYkK-0007ow-H7 for guile-devel@gnu.org; Fri, 16 Dec 2011 09:26:48 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RbYkE-0007Cq-Ul for guile-devel@gnu.org; Fri, 16 Dec 2011 15:26:42 +0100 Original-Received: from p508edf03.dip.t-dialin.net ([80.142.223.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Dec 2011 15:26:42 +0100 Original-Received: from dak by p508edf03.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Dec 2011 15:26:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 27 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508edf03.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) Cancel-Lock: sha1:apti//IYNcAgYZAa8FaeK5ckA0Q= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:13139 Archived-At: Peter TB Brett writes: > David Kastrup writes: > >>> * I still wouldn't be surprised if `local-eval' does the wrong thing if >>> (current-module) is different from what it was when the associated >>> `primitive-eval' was called. >> >> Before anyone even _defines_ what the "right thing" would be, there is >> little point in worrying about this. I don't think that `local-eval' >> 1.8 documented any behavior for this case (well, it did not document any >> behavior for a lot of cases). >> >> So it probably makes sense to look afterwards what will happen without >> special precautions, and unless that is spectacularly useless or >> inconsistent, call it the "right thing" by definition. > > Maybe it makes even more sense (at this stage) to state that the > behaviour in this case is undefined? In my opinion it does not make sense at this stage to state anything. Declaring the behavior as being undefined is premature when further work might discover that it makes eminent sense to define it in a particular way. -- David Kastrup