[R6RS] How SRFI 35 enables communication protocols via conditions

[Marc Feeley]

On 9-Jun-05, at 1:41 AM, Manuel Serrano wrote:

>>>> If you mean that a condition type should correspond to a record  
>>>> type,
>>>>
>>> Yes. That's exactly what I meant.
>>>
>>
>> I see---could you provide a rationale?
>>
> I will try to do that...
>
> 1- We are planning to add aggregate types in Scheme, i.e. records.
> 2- Up to now, the only place, in the R6Rs, where we might use  
> aggregate
>    types is for modeling exceptions (or conditions if you prefer).
>
> If it turns out that the "official" aggregate types (records) that we
> are up to add are not powerful enough to model exceptions it's because
> our design is bad. It can be the design of the aggregate types or the
> design of exceptions.

I agree.  It seems to me that if the R6RS includes the concept of  
multiple inheritance in the exception system, then multiple  
inheritance should also exist in the record system.  Making a special  
case for the condition types leads to an inconsistent design.  But I  
think it is premature to support multiple inheritance in the record  
system.

Moreover I think that multiple inheritance is not the right approach  
for conditions.  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.

Gambit currently uses this approach for some exceptions.  See for  
example the exception uncaught-exception in SRFI 18 (multithreading  
support).  It has a "reason" field which indicates which exception  
was not caught by a thread.  Also, Gambit has a scheduler-exception  
(raised by the thread scheduler in the primordial thread) which  
indicates the low-level exception that caused the scheduler to fail.

Marc