[R6RS] How SRFI 35 enables communication protocols via conditions

Michael Sperber sperber
Sun Jun 5 10:53:00 EDT 2005


At the meeting, Marc asked how to specify and implement communication
protocols via SRFI 35.  Here's how it works:

The specification of some API that wants to signal an exceptional
situation defines condition types that it uses to describe the
situation.  (Or just specifies to re-use an existing condition type.)
Where this condition type is situated needs to be specified on a
case-by-case basis.  Here's the language I used for SRFI 68:

> In exceptional situations not described as "it is an error", the
> procedures described in the specification below will raise an
> &i/o-error condition object. Except where explicitly specified,
> there is no guarantee that the raised condition object will contain
> all the information that would be applicable. It is recommended,
> however, that an implementation of this SRFI provide all information
> about an exceptional situation in the condition object that is
> available at the place where it is detected.

However, as Marc pointed out, when raising an exception, you're often
in a position to provide more information than the specification
requires you to provide.  So the raised condition object still needs
to meet the specification, but also needs to represent more
information that interested parties on the receiving end can interpret
in a meaningful manner.  There's two ways of doing that:

- If the additional information is simply a refinement of the
  condition type in the specification, the raise can simply specify a
  condition object belonging to a subtype of the specified type.

- If it is not, and instead just a piece of additional information,
  (for example, information that can be represented by a condition
  type that sits on some other branch of the condition type
  hierarchy), the raise can just combine the required condition object
  with another one containing the additional information.

Both mechanisms are necessary, because it is not uncommon for several
condition types not directly related via subtyping to apply to a given
exceptional situation.  Two examples:

- File I/O errors that are also networking errors.
- Errors that are also or may be bugs.

Condition systems based exclusively on (single) inheritance like PLT's
don't scale to this kind of situation.  It also means that "conditions
are records" only works as an intuition in a meaningless sense---it
also doesn't really matter.  Moreover, once you have compound
condition objects, more mundane aspects (such as providing an optional
error message) fit seamlessly into the framework.

Generally, SRFI 35 is a much more crucial component in a useful
exception system for programs than SRFI 34, because it defines the
infrastructure for communication protocols that programs can use to
talk to each other.  This is why it's comparatively rich.  Moreover,
since it's meant for communication protocols in the exceptional case
and not, say, language extensions, it trades high performance for a
richer substrate.

The condition type hierarchy in SRFI 68 is quite detailed, even though
the specification doesn't require the abstractions to provide the full
detail that they theoretically could: It enables a client to make
sense of the additional information when available.  The challenge is
to specify the required information in such a way as to provide the
useful information in the common case, and relegate the less common
information, which may be harder to provide, to the optional part.

A note on alternative designs:

- Common Lisp and Dylan use multiple inheritance for compound
  condition types, but, AFAWCD, compound conditions are almost always
  ad-hoc, while the condition hierarchies that are used for
  specifications use only single inheritance.

- In principle, (withdrawn) SRFI 12 (by Will, Kent, Matthew, and Marc)
  provides capability similar to SRFI 35, but specifying a hierarchy
  of condition types using the abstractions there is significantly
  painful.  (It looks good on paper but doesn't work out in practice.
  I wanted to use SRFI 12 as a basis for SRFI 35, but found out the
  hard way that it doesn't work well.)

I hope this illuminates the major design decisions Richard and I made
for SRFI 35.  Please ask if anything is still unclear.

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


More information about the R6RS mailing list