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: Thu, 04 Mar 2004 01:20:19 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87n06xqx8c.fsf@ivanova.rotty.yi.org> References: <87k7278ak9.fsf@alice.rotty.yi.org> <853c8paphg.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 1078562642 30535 80.91.224.253 (6 Mar 2004 08:44:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 6 Mar 2004 08:44:02 +0000 (UTC) Cc: Guile Users , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Mar 06 09:43:52 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 1AzXPT-0003Jj-00 for ; Sat, 06 Mar 2004 09:43:51 +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 1AzXP2-0000jM-W8 for guile-devel@m.gmane.org; Sat, 06 Mar 2004 03:43:25 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1AyenG-0007cs-IZ for guile-devel@gnu.org; Wed, 03 Mar 2004 17:24:46 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1Ayemj-0007Wm-0l for guile-devel@gnu.org; Wed, 03 Mar 2004 17:24:44 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.30) id 1Ayemi-0007Wc-8q for guile-devel@gnu.org; Wed, 03 Mar 2004 17:24:12 -0500 Original-Received: (qmail 24396 invoked by uid 65534); 3 Mar 2004 22:24:07 -0000 Original-Received: from chello212186006140.401.14.univie.teleweb.at (EHLO garibaldi) (212.186.6.140) by mail.gmx.net (mp008) with SMTP; 03 Mar 2004 23:24:07 +0100 X-Authenticated: #3102804 Original-Received: from ivanova.rhinosaur.lan ([192.168.1.9] helo=ivanova) by garibaldi with esmtp (Exim 4.30) id 1AyemJ-0000uR-7Z; Wed, 03 Mar 2004 23:23:47 +0100 Original-Received: from andy by ivanova with local (Exim 4.30) id 1Aygb5-0001py-48; Thu, 04 Mar 2004 01:20:19 +0100 Original-To: Neil Jerram In-Reply-To: <853c8paphg.fsf@ossau.uklinux.net> (Neil Jerram's message of "03 Mar 2004 16:02:03 +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:3483 gmane.lisp.guile.user:2891 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3483 Neil Jerram writes: > Andreas Rottmann writes: > >> Hi! >> >> I just wanted to announce that I've been working a bit on a >> GOOPS-based implementation of SRFI-35 ("Conditions"). It seems to >> basically work, except compound conditions, which are not-yet >> implemented. My implementation is based on the SRFI reference >> implementation, but differs a good deal because it uses GOOPS classes >> instead of SRFI-9 ("Defining record types"). > > Without having looked yet at your code, I think this is nice, because > it ties in with my general thoughts on how we might enhance Guile's > existing errors and exceptions and unify them with the proposals in > SRFIs 34, 35 etc. > > So perhaps this is a good time to share and discuss those thoughts. > In my view there are two main problems with Guile's current > errors/exceptions. > > - A given error/exception - i.e. a collection of throw args - is not > at all self-describing as regards how the catcher should deal with > it, print an error message, etc. > > - There is no way to say sthg like "I want to catch all system > errors", or "all numerical erros". > I've thought of this, too; this was my reason to use GOOPS in the first place. > 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). 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)) > The second problem is solved by arranging > error/exception classes in an inheritance hierarchy, and enhancing > `catch' so that it catches all errors/exceptions that satisfy `(is-a? > KEY)'. > First part (inheritance hierarchy) also done. > If this is accepted, I further think that the errors/exceptions in the > new class hierarchy should be identical with the conditions specified > 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. > Even further, I think it follows that `throw' can become identical to > SRFI-34's `raise', with back-compatibility preserved by translating > > (throw KEY . ARGS) > > to something like > > (throw (make #:key KEY #:args ARGS)) > > Finally, `catch' could be enhanced so that its KEY is either #t, a > symbol (legacy case) or an error/exception class; and SRFI-34's > `with-exception-handler' and `guard' provide different catching and > handler semantics, but operating on the same kind of > error/exception/condition objects. > > Any comments? > Sounds like a good plan, especially since it's been about that what I was after ;-) Cheers, 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 Python is executable pseudocode, Perl is executable line-noise. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel