From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: slowness in guile 1.8 Date: Sat, 26 May 2007 12:49:54 +0200 Message-ID: <1180176594.4388.29.camel@localhost.localdomain> References: <1180110804.4388.16.camel@localhost.localdomain> <87tzu0pybk.fsf@chbouib.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1180176606 24293 80.91.229.12 (26 May 2007 10:50:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 26 May 2007 10:50:06 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat May 26 12:50:04 2007 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HrtqV-0000M0-Pb for guile-devel@m.gmane.org; Sat, 26 May 2007 12:50:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HrtqV-0007sT-De for guile-devel@m.gmane.org; Sat, 26 May 2007 06:50:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HrtqR-0007sB-D9 for guile-devel@gnu.org; Sat, 26 May 2007 06:49:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HrtqP-0007rz-Sc for guile-devel@gnu.org; Sat, 26 May 2007 06:49:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HrtqP-0007rw-NN for guile-devel@gnu.org; Sat, 26 May 2007 06:49:57 -0400 Original-Received: from ambient.dashsystems.com ([216.27.85.7] helo=kettle.ambient-hosting.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HrtqP-0008KP-D6 for guile-devel@gnu.org; Sat, 26 May 2007 06:49:57 -0400 Original-Received: from localhost.localdomain (ambient-hosting.net [10.1.6.1]) by kettle.ambient-hosting.net (Postfix) with ESMTP id 36D228808E for ; Sat, 26 May 2007 06:49:56 -0400 (EDT) Original-Received: by localhost.localdomain (Postfix, from userid 1000) id 46D9411952E; Sat, 26 May 2007 12:49:55 +0200 (CEST) In-Reply-To: <87tzu0pybk.fsf@chbouib.org> X-Mailer: Evolution 2.10.1 X-detected-kernel: Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6617 Archived-At: Hey Ludovic, Thanks for looking at this! On Fri, 2007-05-25 at 20:12 +0200, Ludovic Court=C3=A8s wrote: > Alas, it breaks the following test in `syntax.test': I'm not sure what "it" is in this case; I assume you mean the fix to module-make-local-var!. > (pass-if "binding is created before expression is evaluated" > (=3D (eval '(begin > (define foo > (begin > (set! foo 1) > (+ foo 1))) > foo) > (interaction-environment)) > 2)) >=20 > This test case illustrates the fact that _internal_ defines are > equivalent to `letrec' (Section 5.2.2); top-level defines should behave > similarly for new variables (Section 5.2.1). I don't know what you are trying to say here; top-level defines do not "behave similarly" to letrec. R5RS says in section 5.2.1: If is not bound, however, then the definition will bind to a new location before performing the assignment, whereas it would be an error to perform a `set!' on an unbound variable. =20 The new variable should be created before the assignment, but _not necessarily before evaluation of the rhs_. > For top-level defines as in `(define round round)', the rule is that > `define' is equivalent to `set!' when the variable is already bound > (Section 5.2.1). This justifies the change made by Marius to > `module-make-local-var!' (above). Only if foo is already bound, in the case you gave, is the test syntactically valid. I think the test is bogus. MzScheme, Gambit, Scheme48, and Guile 1.6 think so too. You have snatched defeat from the jaws of victory ;-) Suggest removing the test. Cheers, Andy. --=20 http://wingolog.org/ _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel