SRFI-35: Conditions

SRFI-35 is implemented in ChezScheme Gauche Guile Kawa MzScheme SISC STklos Scheme48

make-condition-type, condition-type?, make-condition, condition?, condition-has-type?, condition-ref, make-compound-condition, extract-condition, define-condition-type, condition

&condition, &message, &serious, &error message-condition?, condition-message, serious-condition?, 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). This means:

  • 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 caching)

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 class linearization.
  • Guile appears to have a distinct compound-condition class.