From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: GOOPS-based SRFI-35 implementation Date: 03 Mar 2004 16:02:03 +0000 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <853c8paphg.fsf@ossau.uklinux.net> References: <87k7278ak9.fsf@alice.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 1078492423 30909 80.91.224.253 (5 Mar 2004 13:13:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 5 Mar 2004 13:13:43 +0000 (UTC) Cc: Guile Users , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Mar 05 14:13:26 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 1AzF8n-0000YY-00 for ; Fri, 05 Mar 2004 14:13:26 +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 1AzF32-000257-Qp for guile-devel@m.gmane.org; Fri, 05 Mar 2004 08:07:28 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1AyYt4-0006bz-D2 for guile-devel@gnu.org; Wed, 03 Mar 2004 11:06:22 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1AyYsT-00064r-La for guile-devel@gnu.org; Wed, 03 Mar 2004 11:06:17 -0500 Original-Received: from [80.84.72.14] (helo=mail2.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1AyYsS-00062n-PC; Wed, 03 Mar 2004 11:05:44 -0500 Original-Received: from laruns.ossau.uklinux.net (unknown [213.78.80.184]) by mail2.uklinux.net (Postfix) with ESMTP id 1C959409FDF; Wed, 3 Mar 2004 16:05:38 +0000 (UTC) Original-Received: by laruns.ossau.uklinux.net (Postfix, from userid 1002) id CF4AC77AAC; Wed, 3 Mar 2004 16:02:03 +0000 (GMT) Original-To: Andreas Rottmann In-Reply-To: <87k7278ak9.fsf@alice.rotty.yi.org> Original-Lines: 62 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 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:3480 gmane.lisp.guile.user:2886 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2886 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 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. 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)'. 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)'. 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? Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel