From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: GOOPS-based SRFI-35 implementation Date: 06 Mar 2004 12:05:33 +0000 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <85llmerxiq.fsf@ossau.uklinux.net> References: <87k7278ak9.fsf@alice.rotty.yi.org> <853c8paphg.fsf@ossau.uklinux.net> <87n06xqx8c.fsf@ivanova.rotty.yi.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1078931441 888 80.91.224.253 (10 Mar 2004 15:10:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 10 Mar 2004 15:10:41 +0000 (UTC) Cc: Guile Users , guile-devel@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Mar 10 16:10:28 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 1B15Ln-0003nl-00 for ; Wed, 10 Mar 2004 16:10:27 +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 1B15Kw-0001Ly-IC for guile-user@m.gmane.org; Wed, 10 Mar 2004 10:09:34 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1Azamw-0006AJ-IM for guile-user@gnu.org; Sat, 06 Mar 2004 07:20:18 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1AzafP-0005Fa-U9 for guile-user@gnu.org; Sat, 06 Mar 2004 07:13:03 -0500 Original-Received: from [80.84.72.14] (helo=mail2.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1Azaet-00059x-36; Sat, 06 Mar 2004 07:11:59 -0500 Original-Received: from laruns.ossau.uklinux.net (unknown [213.78.94.198]) by mail2.uklinux.net (Postfix) with ESMTP id 9C0F4409FAC; Sat, 6 Mar 2004 12:11:46 +0000 (UTC) Original-Received: by laruns.ossau.uklinux.net (Postfix, from userid 1002) id 0D29C77CBC; Sat, 6 Mar 2004 12:05:34 +0000 (GMT) Original-To: Andreas Rottmann In-Reply-To: <87n06xqx8c.fsf@ivanova.rotty.yi.org> Original-Lines: 99 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.2 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:2901 gmane.lisp.guile.devel:3488 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3488 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. > > I think the solution to both these is that an error/exception should > > be an instance of a GOOPS error/exception class (+ subclasses). The > > first problem is then solved by the class slots showing what > > information is available about the error/exception, and class methods > > to - for example - print a human-readable message describing the > > error/exception. > > > So far, this is all implemented in my srfi-35 stuff as in my > Archive. I have additionally exported a handle-condition generic, > whose methods call (error "unhandled foo"), foo being an error > condition, message, serious condition. 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'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. > 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.) 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?) > > 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, 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 (...)) 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. Regards, Neil _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user