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.
References: <199910160912.FAA15873@xxxxxxxxxxxxxxx> From: Per Bothner <per@xxxxxxxxxxx> Richard Kelsey <kelsey@xxxxxxxxxxxxxxxxxxx> writes: > 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*. By `program' I meant a pile of code whose internal interfaces are not fixed. Call it a module if you like. Plain exceptions handling is used in regular programming. CL-style conditions, restarts, etc are usually not. That does suggest they should be separate SRFIs. I don't understand your distinction between `plain exceptions' and CL-style conditions. The restarts are definitely a separate issue, whether they are used to communicate with the user or with other modules. 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. CONDITION? is needed unless either 1. only conditions can be passed to handlers or 2. there are no operations specific to conditions. I can see doing 1 but not 2. Hopefully the authors of SRFI-12 will enlighten as to why they allow values other than conditions to be raised. I think MAKE-COMPOSITE-CONDITION is needed. There are certain to be circumstances where there is more than one type of condition that would be appropriate. How do you choose which one to signal? There was an example of this that came up on the mailing list. If a file is unreachable because of a network problem, do you use the file-not-found condition or the network-unreachable condition? There may be handlers to deal with either or both. You really need to pass both of them. 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 record/object system) is also supported. Why not require a disjoint datatype? What advantage is gained by allowing conditions to also be vectors or whatever? Requiring a disjoint datatype makes for more effecive type checking. -Richard Kelsey