Re: exception systems

[William D Clinger <will@ccs.neu.edu>]

In my previous message I suggested that we were more likely
to end up with a useful exception system if we focus on three
purposes that are clearly implementation-dependent.  Lest
anyone have the contrary impression, I would like to emphasize
that I believe it would be ridiculous to attempt to design or
to standardize an exception system that would allow programs
to achieve those purposes in a portable way.

My point is that exceptions are a ball of mud.  Extensibility
is one of the main reasons for having an exception system.
An exception system that provides a solid foundation for
non-portable extensions will be a far better candidate for
standardization than an exception system that cannot accomodate
non-portable extensions.

In particular, it would be nice for the R5RS exception system
to allow efficient exceptions, so we implementors wouldn't have
to implement a separate exception system underneath it, and so
programmers who need efficient exceptions could use the R5RS
exception system instead of a separate implementation-dependent
system.

Bill Rozas wrote:
> Any asynchronous interrupt delivery system (timer, user interface,
> etc.) is going to be completely library/implementation specific.

Of course.

> Assuming that any exception handling proposal accepted has a way to
> construct/generate/declare new exception types/classes/whatever, and a
> way to signal/raise them from arbitrary code, it should be straight
> forward for asynchronous interrupts to be reflected onto the exception
> handling mechanism if that is desired, thus I'm not sure that we need
> to worry about them beyond keeping these requirements in mind.

Right.  My point was that we need to think about these requirements.

> A different issue is whether we want to talk about agreeing to
> interfaces for such common asynchronous events so that implementations
> that provide them can do so in a compatible way, while not forcing
> other implementations to provide them at all.

That's a good idea that hadn't occurred to me.  To do it right
we need an exception system, though, so let's work on that first.

Kent Pitman wrote:
> I'm not sure what to make of this because it's presented in terms of
> the operator being used and not the functionality being achieved.

The exception system that was proposed last year adds zero
new functionality to Scheme.  Its justification must therefore
be syntactic: improved readability or convenience.

> Does this mean it's criterial that you can't do any non-local
> transfer of control?  Is it EXPLICIT use of continuations that's bad
> but if they're created (and passed to you) implicitly that's ok?
> If no uses are allowed, is it only "full catch" you're trying to avoid?

This is like asking a nonviolent batchelor whether he has stopped
beating his wife.  I don't see any connection between the above
questions and anything that has been said in this thread.  Instead
of trying to answer them, I'll just acknowledge that I must not
have expressed myself very clearly.

> Well, let's be careful with words....
> ...you cannot simply assume that the word
> error, in its casual English usage, will be mirrored by detection code
> in the running image without enormous cost....

I was careful to use the word "error" in the technical sense
of R4RS 1.3.2.

> I think it should not be a goal of any exception system to communicate
> among two modules that know about each other. 

I disagree.  Although an exception system is useful even when
two modules know nothing about each other, exceptions are far
more useful when the code that handles the exception knows a
lot about the code in which the exception occurred.

An exception system is not a mechanism for graceful degradation
in the face of completely unanticipated difficulties, but a
mechanism for creating more readable and efficient programs by
abstracting away from exceptional cases.

> Another issue you didn't mention but that necessarily becomes involved
> in production code and is frequently cited as a weakness in CL's
> condition system is floating point traps.  I think this is really just
> orthogonal, like interrupts, ...

I think floating point traps and interrupts are both important
sources of exceptions.  I agreed with your analysis of asynchronous
interrupts, but I draw an opposite conclusion:  Your analysis shows
that proper handling of asynchronous interrupts presupposes an
adequate exception system.

I mentioned asynchronous interrupts to warn against thinking of
exceptions as uncommon events.  MacScheme was designed to handle
about 10 timer exceptions per second, and often handles about 30
per second in practice.  Nowadays it would be more reasonable to
handle well over a hundred timer exceptions as a matter of course
(faster than the eye can see), and to handle well over a thousand
exceptions per second when profiling, without any noticeable
degradation in performance.

I mentioned mixed-mode arithmetic exceptions to point out that an
exception system really ought to handle a million exceptions per
second without excessive overhead.  I'm not sure it's reasonable
to expect the R*RS authors to design an exception system that
could meet that spec, but if the R5RS design is inefficient then
the implementors will continue to implement their own designs,
and the implementation-dependent nature of the relationship between
those systems and the R5RS system will be a source of confusion to
programmers.

>    IMPLEMENTATION RESTRICTION
>      I think this is usually similar to a domain error
> 
> Btw, I think this is maybe not similar but my r4rs is at home....

In Scheme we think of the continuation and store as implicit
arguments to a procedure, so "storage exhausted" is very much
like a domain error.

I'm not saying this is the way it should be explained in "The
Simple Schemer", but I doubt whether novices have any business
trying to write an exception handler for implementation
restrictions.

SFAIK, IGNORE-ERRORS hasn't been proposed for Scheme.  I presume
that anyone who wants to propose it will also propose a semantics
for it.  I'm not very keen on adding things to the language first
and then figuring out later what they might mean, although we've
certainly done that on several occasions.

Will