Re: GOOPS-based SRFI-35 implementation

[Neil Jerram]

Andreas Rottmann <address@hidden> writes:

> Neil Jerram <address@hidden> writes:
> 
> > Andreas Rottmann <address@hidden> 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