References: <199910160912.FAA15873@kima.nj.nec.com>
   From: Per Bothner <xxxxxx@bothner.com>

   Richard Kelsey <xxxxxx@research.nj.nec.com> 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