>>>>> "Darren" == Darren Bane <xxxxxx@intel.com> writes:

Darren> Although I wouldn't like to see a dependency on other SRFIs, I think a
Darren> section treating compatibility with them would be useful.  Perhaps
Darren> something like the following after the "Standard Conditions" section?

Darren> --begin suggested section----------
Darren> Compatibility with other SRFIs:
Darren> ------------------------------
Darren> SRFI-18, SRFI-21 and SRFI-23 define some standard conditions.  If a
Darren> Scheme implementation provides these SRFIs, it should use the
Darren> following definitions:

Darren> For SRFI-18 and SRFI-21:
Darren>    (define-condition-type &join-timeout &condition
Darren>      join-timeout-exception?)
Darren>    (define-condition-type &abandoned-mutex &serious
Darren>      abandoned-mutex-exception?)
Darren>    (define-condition-type &terminated-thread &condition
Darren>      terminated-thread-exception?)
Darren>    (define-condition-type &uncaught &serious
Darren>      uncaught-exception?
Darren>      (reason uncaught-exception-reason))

There's no reason why these should be in SRFI 35: SRFI 35 is just a
general framework for defining new condition types.  Specific
condition type hierarchies related to specific sets of problems should
be relegated to appropriate separate SRFIs.  See SRFI 36.

(A more specific problem I see is that I can't imagine *any* good
reason why a running program should legitimately be able to catch any
of these exceptions except for JOIN-TIMEOUT.  The rest denote program
bugs, after all.)

Darren> For SRFI-23:
Darren>    (define-condition-type &srfi-23-error &error
Darren>      srfi-23-error?
Darren>      (reason srfi-23-error-reason)
Darren>      (args srfi-23-error-args))
Darren>    (define (make-error-exception r a)
Darren>      (make-condition &srfi-23-error reason r args a))
Darren>    (define (error reason . args)
Darren>      (raise (make-error-exception reason args))
Darren> --end suggested section----------

Moreover, there's no implicit or explicit connection between SRFI 23
and SRFI 34 / SRFI 35: In fact, the reference implementation of SRFI
34 uses ERROR as a primitive means of aborting the running program.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla