[R6RS] How SRFI 35 enables communication protocols via conditions

[Michael Sperber]

Marc Feeley <feeley at iro.umontreal.ca> writes:

> Moreover I think that multiple inheritance is not the right approach  
> for conditions.

I agree---as I said in the message at the top this thread, compound
conditions are typically created ad-hoc, which makes (static) multiple
inheritance an awkard fit.

> I prefer the nested Throwables of Java.  Let me give you an example.
> Say I have a piece of code that can either raise an "file-not-found
> condition" in a call to open-input-file or a "key-not- found
> condition" in a call to a database lookup operation.  In the handler
> you test for the file-not-found condition and then the key-
> not-found condition.  With compound conditions there will be a
> problem if the lookup operation uses the filesystem as a database
> (i.e. it implements the lookup with open-input-file), because both
> conditions are file-not-found conditions.  By nesting conditions
> this problem is avoided, yet it is still possible to know (by
> following the nesting chain) that the key-not-found condition is due
> to a file- not-found condition.

The Java approach seems to have the disadvantage that the regular
condition-type discrimination mechanism (via types in the catch
clauses) only applies to the outermost condition object---you have to
apply more elaborate tests to find specific condition types along the
chain.  (It may be they added more magic to make this work---maybe
Marc or Anton could help elucidate.)  There certainly isn't always a
natural order to the component conditions.

Having an explicit nesting chain is also no problem with SRFI 35.
Just add:

(define-condition-type &nested &condition
  nested-condition?
  (inner nested-condition-inner))

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla