Re: GOOPS-based SRFI-35 implementation

[Neil Jerram]

Andreas Rottmann <address@hidden> 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 <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?

        Neil