SRFI-35 is implemented in ChezScheme Gauche Guile Kawa MzScheme SISC STklos Scheme48
make-condition, condition?, condition-has-type?,
condition-ref, make-compound-condition, extract-condition,
&condition, &message, &serious, &error
Integration of srfi-35 condition hierarchy and CLOS-style object system
If the implementation supports CLOS-style object system, it may be
natural to map each condition type to each class.
Then (condition-has-type? cond type) is just a (is-a? cond type).
However, this might cause a problem with compound conditions.
If we want to keep condition-has-type? vs is-a? equivalence,
(make-compound-condition cond0 cond1 ...) has to create a subclass
that inherits all of (class-of condN).
- make-compound-condition can fail if it can't find a consistent
class precedence list (srfi-35 itself only allows single inheritance
for condition types, and there's no way to access the implicit multiple
inheritance created by make-compound-condition; but the user may use
his/her own mixin classes for conditions).
- creating compound condition may be very heavy, for it may go through
whole class definition protocol (although this may be alleviated by
Different implementations seem to approach this differently.
- STklos supports srfi-35 since 0.58. It maps condition types
to built-in struct types (make-struct-type), and uses hard-wired
multiple inheritance mechanism for compound condition types.
It only deals with simple slot inheritance and doesn't go through
- Guile appears to have a distinct compound-condition class.