From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: GOOPS-based SRFI-35 implementation Date: Sat, 06 Mar 2004 15:52:36 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87y8qevxhn.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 1078940427 28775 80.91.224.253 (10 Mar 2004 17:40:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 10 Mar 2004 17:40:27 +0000 (UTC) Cc: Guile Users , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 10 18:40:10 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 1B17gg-0000lN-00 for ; Wed, 10 Mar 2004 18:40:10 +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 1B17bu-00084i-0Y for guile-devel@m.gmane.org; Wed, 10 Mar 2004 12:35:14 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1AzdHb-0003ii-7V for guile-devel@gnu.org; Sat, 06 Mar 2004 10:00:07 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1AzdH3-0003Nt-O7 for guile-devel@gnu.org; Sat, 06 Mar 2004 10:00:05 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.30) id 1AzdH2-0003MZ-U4 for guile-devel@gnu.org; Sat, 06 Mar 2004 09:59:33 -0500 Original-Received: (qmail 16259 invoked by uid 65534); 6 Mar 2004 14:52:48 -0000 Original-Received: from chello212186006140.401.14.univie.teleweb.at (EHLO garibaldi) (212.186.6.140) by mail.gmx.net (mp015) with SMTP; 06 Mar 2004 15:52:48 +0100 X-Authenticated: #3102804 Original-Received: from ivanova.rhinosaur.lan ([192.168.1.9] helo=ivanova) by garibaldi with esmtp (Exim 4.30) id 1AzdAL-0003lq-SA; Sat, 06 Mar 2004 15:52:37 +0100 Original-Received: from andy by ivanova with local (Exim 4.30) id 1AzdAK-00022g-Tp; Sat, 06 Mar 2004 15:52:36 +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-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3489 gmane.lisp.guile.user:2903 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3489 Neil Jerram writes: > Andreas Rottmann writes: > >> Neil Jerram writes: >> >> > Andreas Rottmann writes: >> > >> I've thought of this, too; this was my reason to use GOOPS in the >> first place. > > Great - our thoughts are very much in sync then. In my view, though, > the whole idea becomes much nicer and more useful if we integrate it > with existing Guile exceptions, so I hope we can agree with Marius to > do this. > Indeed. Making Guile use SRFI-35 conditions everywhere would be a *very* nice thing to have. >> Also, there is a class &compound-condition which doesn't exist in >> the SRFI (so methods for compund conditions can be defined). > > Seems sensible; also that it doesn't exist in the SRFI, because > &compound-condition is not a condition _type_ (even though it does > make sense as a GOOPS class). Do you have an example in mind of how > methods on &compound-condition can be useful? > I've so far only used it this way: (define-method (handle-condition (c &compound-condition)) (cond ((and (message-condition? c) (error? c)) (format (current-error-port) "itla-debuild: ~A\n" (condition-message c)) (if (abort-condition? c) (exit 1))) (else (format #t "itla-debuild: unexpected condition ~S\n" c)))) And then somewhere raise a fatal error: (raise (condition (&message (message (format #f "Current working directory ~S is not part of working copy build area ~S" (getcwd) (string-join wc-area-dirs "/")))) (&abort))) > I'm not sure though about `condition' expanding to > `make-compound-condition' in the case there is only one type given. > Is this implied in some way by the SRFI? I think it would be nicer to > detect the single type case and use `make-condition' instead. > Well, I detect that in make-compound-condition itself, but that's not the most obvious place (since the name make-compound-condition implies that a call will indeed result in a compund condition). >> Plus, there is a macro guard/handle, which calls handle-condition: >> >> (define-method (handle-method (&foobar-condition c)) >> ...) >> >> (guard/handle >> (some-code-that-maz-be-foobar)) > > (Not in the version that you posted, so I presume this is newer.) > Yes, but it's in my Archive: % tla register-archive http://people.debian.org/~rotty/arch/a.rottmann@gmx.at/2004-main % tla get itla--devo--0.1 itla % $EDITOR itla/srfi/srfi-35.scm > Interesting. I'm sceptical that it will be possible to define a > generally useful handler for a condition, but I could easily be wrong, > and there is negligible overhead from providing this. (On the other > hand, it's only a few lines, so perhaps could be left to the > programmer to write for him/herself when needed?) > I think this might come handy for top-level handlers. If there is general consensus, I could take this out of (srfi srfi-35), of course. >> > by SRFI-35. Therefore, for example, `make-condition' would create and >> > return a GOOPS error/exception class and, given a >> > error/exception/condition object OBJ, `(condition-has-type? OBJ TYPE)' >> > would be identical to `(is-a? OBJ TYPE)'. >> > >> I'd have to specialize is-a? for this, since compound conditions all >> share a class. > > 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, > That was my initial idea, I then however switched to a separate class for some reason. "compound-condition-is-derived-class" seems like a more coherent design to me now, however. > 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 (...)) > > but I think this is achievable. > > This conflicts, though, with the introduction of &compound-condition > and the idea that &compound-condition provides a way to define methods > on compound conditions. Since this ability is a Guile extension > anyway (w.r.t. SRFI-35), I think it would be reasonable to say that > the way to do this is to define the compound condition class > explicitly, using define-class as just above. > Sounds like a good plan, I'll look into this. 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 If atheism is a religion, then health is a disease. -- Clark Adams _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel