[R6RS] How SRFI 35 enables communication protocols via conditions

[Michael Sperber]

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

> On 9-Jun-05, at 11:52 AM, Michael Sperber wrote:
>
>> For example, in the bug vs. error scenario: it's not that one is the
>> *cause* of the other.
>
> Could you elaborate on this example?  I'm not sure I follow your  
> argument.  If you have other examples where there is no causal  
> relationship please give them.

I'll try.  Here's a typical aggregation example from SRFI 68 reference
implementation:

    (raise
     (condition
      (&message
       (message "reader-get-position operation not available"))
      (&i/o-operation-not-available-error
       (operation reader-get-position))
      (&i/o-reader/writer-error
       (reader/writer reader))))

An "operation not available" condition is completely orthogonal to a
condition that supplies a reader or writer.  Ordering them in a
single-inheritance subclass hierarchy is bound to get it wrong for
some cases, or make the hierarchy unnecessarily verbose while
weakening the communication protocol.

> Perhaps you are talking about the "eval" example, where an error in  
> the expression being evaluated by eval is a bug in the program that  
> called eval.  To me this means that eval will wrap the "error"  
> condition in a "bug" condition so there is a causal relationship.

No, that's not it: you're right in that eval clearly has a causal
relationship.

Matthew explained this to me---let's say, you're writing contracts
that run along with your code.  Is an exception that occurs in a
contract a bug or a "regular" error?  You get into situations where
you can't tell, and might want to talk to handlers that catch either
kind (bugs or errors).  (Matthew can probably explain this much more
clearly than I can---he certainly came up with some convincing
concrete instances that have turned all mushy in my brain.)

A lot of these situations come down to ambiguities in the existing
taxonomy---your problem fits several descriptions, but you know some
handlers look only for one, and some look only for the other, and you
want control over which ones you want to contact.  For example, what
about "division by zero"?  Is an error that occurred when writing to a
pipe a read error or a write error?

(In case I didn't say this clearly before: I think that expressing a
causal relationship is a useful way of thinking about conditions and
your argument has convinced me that we should probably have a standard
condition type for it; it's just not the only one.)

>>   Also, in the "network vs. file-system error"
>> scenario, one *is* the cause for the other, but it's not clear why a
>> handler with a `network-error?' predicate shouldn't be able to catch
>> the condition.  What if, when I'm signalling the exception, I want to
>> talk to *either* the handler for network errors or file-system errors?
>
> By "either" you mean one or the other, but you don't care which, or  
> is there some kind of ordering between the handlers from the raiser's  
> point of view?  Doesn't this lead to problems (for example when  
> changing the implementation of a module).  Why is the handler  
> interested in the details of the implementation?

Sorry for being unclear---I meant that I don't care which.

Let's say I have a handler that, in the face of a network error, tries
to redial the ISP.  This handler doesn't know anything about
file-system errors, so it'll have to have to use a special predicate
that descends down the chain.  The problem is that the handler may
exist in a part of the program that you have no control over, and just
uses `network-error?' to detect the situation.  What do you do when
you're writing the code creating the condition object?  You have the
choice of throwing away information or not being able to talk to the
other guy, both of which are bad. 

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