Re: GOOPS-based SRFI-35 implementation

[Andreas Rottmann <a.rottmann@gmx.at>]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Andreas Rottmann <a.rottmann@gmx.at> 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 <legacy-exception> #: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