Richard Kelsey <xxxxxx@research.nj.nec.com> 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
xxxxxx@pacbell.net  xxxxxx@bothner.com   http://www.bothner.com/~per/