This page is part of the web mail archives of SRFI 35 from before July 7th, 2015. The new archives for SRFI 35 contain all messages, not just those from before July 7th, 2015.
>>>>> "Darren" == Darren Bane <darren.bane@xxxxxxxxx> 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