[R6RS] How SRFI 35 enables communication protocols via conditions

[Marc Feeley]

On 9-Jun-05, at 10:41 AM, Michael Sperber wrote:

> 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.

You say it is a disadvantage, but I see this as an advantage (in  
Scheme).  I don't want the implementation of the operations to be  
directly visible to the exception catcher, for abstraction reasons.   
The low-level (implementation) details are there if you need to get  
to them but I expect most exception catchers to be interested in the  
exceptions declared in the spec for the operations (as opposed to the  
implementation of these operations).  Of course (in Scheme) nothing  
prevents someone from defining predicates that walk down the "cause"  
chain to match the condition they are interested in if they wish to  
break the abstraction.

>   (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))
>

Sure SRFI 35 is more general.  That's my point.  It is overkill (in  
the sense that compound conditions are not necessary).

Marc