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: Re: macros, procedure->macro Date: Mon, 8 Jul 2002 22:23:22 +0200 (CEST) Sender: guile-devel-admin@gnu.org Message-ID: References: <87n0t376c9.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1026159894 7400 127.0.0.1 (8 Jul 2002 20:24:54 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 8 Jul 2002 20:24:54 +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 17Rf42-0001vE-00 for ; Mon, 08 Jul 2002 22:24:54 +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 17Rf3F-0004G0-00; Mon, 08 Jul 2002 16:24:05 -0400 Original-Received: from sallust.ida.ing.tu-bs.de ([134.169.132.52]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17Rf2e-0004FB-00; Mon, 08 Jul 2002 16:23:28 -0400 Original-Received: from localhost (dirk@localhost) by sallust.ida.ing.tu-bs.de (8.9.3+Sun/8.9.1) with ESMTP id WAA12791; Mon, 8 Jul 2002 22:23:23 +0200 (CEST) Original-To: Marius Vollmer In-Reply-To: <87n0t376c9.fsf@zagadka.ping.de> 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:759 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:759 On 7 Jul 2002, Marius Vollmer wrote: > 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. OK, I have changed the definitions of define-generic and define-accessor to only show their re-defining behaviour if executed on top-level. I also changed all three (define-class, define-generic and define-accessor) to use mmacros, which then would not change their behaviour at all. Finally, I changed define-class in stklos.scm to also use a mmacro, which is also safe if no other 'define-class' code uses macros any more. That means, after I have checked these changes in, guile itself will be clean of using the built-in so called "macros", which are not really macros in the scheme sense. > Redefinitions on the top-level do make sense and can be supported by a > normal macro via explicit module manipulations, i.e. [...] I am not sure I like the way, goops is based on names instead of objects at a lot of places. For example, it is not possible to do the following: (use-modules (oop goops)) (define-generic G) (define (get-generic) G) (define-class () (x #:accessor (get-generic))) because instead of a value, define-class expects a symbol after the #:accessor keyword. Automatic redefinition of classes is IMO a critical issue: Redefinition of a class means to change the structure of all objects of the class that already exist. This should be a well considered step and should not happen automatically (I am not even sure whether it is a good idea at all). It is not too inconvenient to request the user to call class-redefinition instead of define-class. It will inhibit accidential redefinitions. Just my opinion... Best regards Dirk Herrmann _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel