From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: define and modules Date: Sun, 20 Oct 2002 18:17:04 +0200 (CEST) Sender: guile-devel-admin@gnu.org Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1035130777 12033 80.91.224.249 (20 Oct 2002 16:19:37 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 16:19:37 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 183Ing-00037x-00 for ; Sun, 20 Oct 2002 18:19:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 183ImF-0005S1-00; Sun, 20 Oct 2002 12:18:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 183IlO-0004UX-00 for guile-devel@gnu.org; Sun, 20 Oct 2002 12:17:14 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 183IlG-00043S-00 for guile-devel@gnu.org; Sun, 20 Oct 2002 12:17:11 -0400 Original-Received: from sallust.ida.ing.tu-bs.de ([134.169.132.52]) by monty-python.gnu.org with esmtp (Exim 4.10) id 183IlF-0003yS-00 for guile-devel@gnu.org; Sun, 20 Oct 2002 12:17:06 -0400 Original-Received: from localhost (dirk@localhost) by sallust.ida.ing.tu-bs.de (8.9.3+Sun/8.9.1) with ESMTP id SAA12293 for ; Sun, 20 Oct 2002 18:17:04 +0200 (CEST) Original-To: guile-devel@gnu.org Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1575 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1575 On 19 Oct 2002, Marius Vollmer wrote: > Dirk Herrmann writes: > > > Summarized: > > * The compiler must be able to emit code that allows references to > > identifiers to be looked up at use time (that is, in the executor). > > * The executor must be able to handle definitions. > > * Once a binding has been referenced, the binding should not change. > > Yes, that's exactly the way I see it as well. The constraints that > new-model.txt puts on the module system work in this direction. Great. However, currently, guile's handling of defines is buggy or at least in contrast to R5RS. Changing it would break existing code as shown in the following two examples: Example 1: ========== (define x (begin (set! x #f) #t)) --> ERROR: Unbound variable: x If I understand R5RS correctly, (define x y) should first bind the identifier x to a location and _then_ execute the assignment (set! x y). That means, guile's behaviour is wrong here. The reason is, that guile first executes y and _afterwards_ binds and assigns x. This bug could be fixed by changing the order in which guile deals with defines. However, then we would have a problem with the following code: Example 2: ========== (define-module (guile)) (define foo #t) (define-module (bar)) foo --> #t (define foo (not foo)) foo --> #f (define-module (guile)) foo --> #t According to R5RS, a 'define expression on the top-level has exactly the same effect as an assignment expression if the identifier is bound. Guile, however, behaves differently here: An expression (define x y) executes y making use of bindings that potentially come from other modules. Then, if x is bound _within_the_current_module_ an assignment is performed. Otherwise, if x is not bound or bound in another module, a new binding is created in the current module. Example 1 and 2 show two aspects where the current handling of guile's define is wrong (with respect to R5RS): First, if a binding exists, guile does not simply perform an assignment, and second, if no binding exists, guile does not as a first step create one. Unfortunately, there is code that depends on this behaviour: (define-module (srfi srfi-17) ...) ... (define setter (getter-with-setter setter (lambda args (error "Setting setters is not supported for a good reason.")))) In fact, the way guile currently handles 'define expressions, bindings get re-defined after they have been referenced! Look at the following expression: (define-module (guile)) (define foo #t) (define-module (bar)) (define (old) foo) ; references the old binding in module (guile) (old) --> #t (define foo #f) ; new binding for foo in module (bar) (define (new) foo) ; references the new binding in module (bar) ;; and now: ;; new and old reference different bindings for foo: (new) --> #f (old) --> #t Best regards, Dirk Herrmann _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel