From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: GOOPS-based SRFI-35 implementation Date: Mon, 08 Mar 2004 21:07:45 +0100 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <87r7w3yuem.fsf@ivanova.rotty.yi.org> References: <87k7278ak9.fsf@alice.rotty.yi.org> <853c8paphg.fsf@ossau.uklinux.net> <87n06xqx8c.fsf@ivanova.rotty.yi.org> <85llmerxiq.fsf@ossau.uklinux.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1079014386 2059 80.91.224.253 (11 Mar 2004 14:13:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 11 Mar 2004 14:13:06 +0000 (UTC) Cc: Guile Users , guile-devel@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Mar 11 15:13:01 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B1Qvk-0005Uz-00 for ; Thu, 11 Mar 2004 15:13:00 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B1QQm-00086S-UA for guile-user@m.gmane.org; Thu, 11 Mar 2004 08:41:00 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B0R3x-0008Hg-2R for guile-user@gnu.org; Mon, 08 Mar 2004 15:09:21 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B0R2w-00081k-6X for guile-user@gnu.org; Mon, 08 Mar 2004 15:08:49 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.30) id 1B0R2v-00080e-2A for guile-user@gnu.org; Mon, 08 Mar 2004 15:08:17 -0500 Original-Received: (qmail 25250 invoked by uid 65534); 8 Mar 2004 20:08:12 -0000 Original-Received: from chello212186006140.401.14.univie.teleweb.at (EHLO garibaldi) (212.186.6.140) by mail.gmx.net (mp008) with SMTP; 08 Mar 2004 21:08:12 +0100 X-Authenticated: #3102804 Original-Received: from ivanova.rhinosaur.lan ([192.168.1.9] helo=ivanova) by garibaldi with esmtp (Exim 4.30) id 1B0R2P-0000s1-Nm; Mon, 08 Mar 2004 21:07:45 +0100 Original-Received: from andy by ivanova with local (Exim 4.30) id 1B0R2P-00033x-HH; Mon, 08 Mar 2004 21:07:45 +0100 Original-To: Neil Jerram In-Reply-To: <85llmerxiq.fsf@ossau.uklinux.net> (Neil Jerram's message of "06 Mar 2004 12:05:33 +0000") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) X-Spam-Score: -4.9 (----) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:2915 gmane.lisp.guile.devel:3503 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3503 Neil Jerram writes: > Hmm. My inclination is that it would be nicer if a compound condition > straightforwardly satisfied is-a? for all its component condition type > classes (without specialization of is-a?). > > The big benefit of this is that methods defined for the component > types will work on (instances of) the compound type as well, which > makes sense because we know that the compound type has all the slots > of the component type. > > The possible problem is that `make-compound-condition' would have to > construct an appropriate subclass on the fly, and that this should > interact nicely with compound condition classes created explicitly by > the programmer, e.g.: > > (define-class &my-condition (&i/o-condition &runtime-condition) > ...) > > In other words, given this define-class, the result of > > (make-condition &my-condition ...) > > should be indistinguishable from that of > > (make-compound-condition &i/o-condition (...) > &runtime-condition (...)) > I think you mean condition instead of make-compound-condition here. > but I think this is achievable. > It may be, but this probably involves "caching" defined (via define-class or the condition macro) condition types by their supertypes. This, in turn, disallows defining different define-class statements specifiying the same supers (if the supers are conditions). Another, much more serious problem is the following: (define-condition-type &c &condition c? (x c-x)) (define-condition-type &c1 &c c1? (a c1-a)) (define-condition-type &c2 &c c2? (b c2-b)) (define v2 (condition (&c2 (x "V2") (b "b2")))) (define v3 (condition (&c1 (x "V3/1") (a "a3")) (&c2 (b "b3")))) (define v5 (make-compound-condition v2 v3)) ;; This is hairy Here, we given your proposed model, we'd get this hierarchy: (define-class &c ()) (define-class &c1 (&c)) (define-class &c2 (&c)) (define-class &c3 (&c1 &c2)) ;; Class constructed for v3 (define-class &c5 (&c2 &c3)) ;; Class constructed for v5 This will cause GOOPS to barf: "merge-lists: Inconsistent precedence graph" I didn't see an obvious solution to this problem. Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.rottmann@gmx.at http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Make free software, not war! _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user