[R6RS] How SRFI 35 enables communication protocols via conditions
Thu Jun 9 07:42:09 EDT 2005
On 9-Jun-05, at 1:41 AM, Manuel Serrano wrote:
>>>> If you mean that a condition type should correspond to a record
>>> 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
> 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
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-
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.
More information about the R6RS