From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.user Subject: Re: macros, procedure->macro Date: 07 Jul 2002 20:15:02 +0200 Sender: guile-user-admin@gnu.org Message-ID: <87n0t376c9.fsf@zagadka.ping.de> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1026101980 23697 127.0.0.1 (8 Jul 2002 04:19:40 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 8 Jul 2002 04:19:40 +0000 (UTC) Cc: Gary Houston , guile-devel@gnu.org, guile-user@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17RPzw-0006A4-00 for ; Mon, 08 Jul 2002 06:19:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17RPzp-00038L-00; Mon, 08 Jul 2002 00:19:33 -0400 Original-Received: from monty-python.gnu.org ([199.232.76.173] helo=monty-python) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17RPqt-0001RL-00 for ; Mon, 08 Jul 2002 00:10:19 -0400 Original-Received: from dialin.speedway42.dip183.dokom.de ([195.138.42.183] helo=zagadka.ping.de) by monty-python with smtp (Exim 4.05) id 17RGYp-00088F-00 for guile-user@gnu.org; Sun, 07 Jul 2002 14:15:03 -0400 Original-Received: (qmail 7080 invoked by uid 1000); 7 Jul 2002 18:15:02 -0000 Original-To: Dirk Herrmann In-Reply-To: Original-Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:710 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:710 Dirk Herrmann writes: > So what is so special about the uses of procedure->macro at the places > above? > > [checking for redefinitions.] We need to restrict this redefining behavior of 'define-class' et all to the top-level. Local class definitions should not redefine classes outside of their scope (that would lead to a funny version of dynamic scoping of classes, eew), and redefinitions directly in one scope should be an error, just like any other definitions. For example, (let ((foo (find-class ""))) (define-class foo ...) ...) should not try to redefine the class that is the value of the location bound to foo by the let. It should simply shadow the outer foo. Also, (let () (define-class foo ...) (define-class foo ...) ...) should be an error, just like (let () (define foo ...) (define foo ...)) Redefinitions on the top-level do make sense and can be supported by a normal macro via explicit module manipulations, i.e. (define-class foo ...) => (module-define-class (current-module) 'foo ...) with (define (module-define-class mod sym ...) (let* ((var (module-ensure-local-variable! mod 'foo)) (class (make-class ...))) (if (variable-bound? var) (redefine-class (variable-ref var) class)) (variable-set! var class))) _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user