This page is part of the web mail archives of SRFI 12 from before July 7th, 2015. The new archives for SRFI 12 contain all messages, not just those from before July 7th, 2015.
Richard Kelsey <kelsey@xxxxxxxxxxxxxxxxxxx> writes: > Exceptions and conditions have been discussed at length on the > Scheme Author's mailing list. ... Thanks for the link, which I've now book-marked. I did some skimming of the Archive as well as the Conditions chapter of CLtL:2. > The quick answer is that exception systems are used to communicate > between programs. That is an unusual viewpoint. In most languages, exception systems are used to separate normal from abnormal results when communicating between *modules*. However, I noticed in CLtL:2 a major emphasis on communicating between the program and the user via the debugger. I.e. an emphasis on what one might call "meta-programming" or "interactive reflection". For example eval and the MOP fall into the same category. These are useful features, but handly the stuff of "regular" programs. Instead, they are part of the programmer's toolbox. Plain exceptions handling is used in regular programming. CL-style conditions, restarts, etc are usually not. That does suggest they should be separate SRFIs. Admittedly, the conditions in srfi-12 are not very complex or "meta" per se. But I do think they could be simplified. For example the need for MAKE-COMPOSITE-CONDITION and CONDITION? is controversial. I do agree conditions (or whatever they are called) should be standardized and not just be arbitrary objects. But I don't see any need to support signaling anything *else*, and thus we don't need a disjoint datatype. Using a disjoint datatype can be *recommended*, but should be be required, unless srfi9 (or some alternative recurd/object system) is also supported. And I still think "condition" is not the right name for the datatype that gets passed by the exceptions handling system. "exception" is both less misleading and more standard. "signal" also works. -- --Per Bothner bothner@xxxxxxxxxxx per@xxxxxxxxxxx http://www.bothner.com/~per/