Re: exception systems

[Jeff Dalton <jeff@aiai.ed.ac.uk>]

>    1.  So an application can use exceptions as a control structure
>    without having to load an SLIB module or use
>    CALL-WITH-CURRENT-CONTINUATION.
> 
> Avoiding the loading of files (assuming that this condition is not
> directed solely to SLIB files) is a major new restriction on
> implementations.  Many of SCM's procedures are defined in its Scheme
> initialization file.  What large benefit justifies restricting
> implementations thus?
> 
> [...]

Surely the above is just to say that exceptions should be built into
the language, in some sense, so that you don't have to load code from
a library or roll your own in programs that want to use exceptions.

I think you are reading far too much into it.

>    2.  So an application can give up when it detects an untenable
>    situation.
> 
> This is the situation currently.  An application program has no
> recourse when an error is signaled.

But an application may also want to signal an error / raise
and exception.  So that is a potential purpose for exceptions.

>    4.  So an application can give meaning to some situation that
>    the language standards describe as an error.  For example, an
>    application might want (CAR '()) to evaluate to #f, or (+ LOG EXP)
>    to be (LAMBDA (X) (+ (LOG X) (EXP X))).
> 
> Scheme programs can already can accomplish these tasks by redefining
> CAR and +.  By defining them, a program declares to a compiler that
> these procedures can behave differently from the built-in procedures.
> To redefine built-in procedures by creating exception handlers would
> seem to make compiling extremely difficult.  Procedures would never be
> closed -- a new exception handler could change the behavior of a
> compiled procedure at any time.

I don't understand this.  How do you "redefine" a procedure by
creating an exception handler?  Nor do I see any problem for
compilation.  Could you perhaps give an example?

-- jeff