Re: R5RS meeting at Xerox PARC

[david carlton <carlton@husc.harvard.edu>]

I'd like to see some sort of error system in the standard.  Being a
poor student on the other coast, I won't be able to be at the meeting
to discuss it, I'm afraid, but here's the sort of thing that I have in
mind:

(EXCEPTION <string>)
  Returns a new exception object.  The string <string> will be passed
  to the handler for the exception in order to allow it to print a
  message describing the exception.

(RAISE <exception>)
  This calls the handler for <exception>, passing it the <string> used
  in the creation of <exception> as an argument. 

(WITH-HANDLER <thunk> <exception1> <function1> <exception2> <function2> ...)
  This calls <thunk> and returns its value.  If one of the
  <exception>s is raised during the execution of <thunk>, the
  corresponding <function> is invoked with the continuation of the
  WITH-HANDLER as its continuation and the <string> used in the
  definition of the <exception> as its argument.

(SET-DEFAULT-HANDLER! <exception> <function>)
  This sets the default handler for <exception> to be <function>.
  This handler is called if <exception> is RAISEd and no other handler
  has been bound by a WITH-HANDLER form.  The continuation that
  <function> has when it is invoked as a handler is undefined.  

(DEFAULT-HANDLER <exception>)
  This returns the default handler for <exception>.


This isn't great.  The <strings> can be eliminated and probably
should.  Perhaps RAISE should take more optional arguments to pass
along more information.  It might well be better to have WITH-HANDLER
take only two arguments, namely <thunk> and a list of (<exception>
<function>) lists; or to take three arguments, and to require separate
calls to WITH-HANDLER to bind separate exceptions.  There is the
question of what should happen if a continuation captured outside of a
WITH-HANDLER is invoked within the <thunk> of the WITH-HANDLER, and
vice-versa - I think that implementations should be required to do the
right thing in situations like

(with-handler
 (lambda ()
   (with-handler
    (lambda ()
      (with-handler
       (lambda ()
	 (raise exception1))
       exception2
       handler1))
    exception1
    handler2))
 exception2
 handler3)

i.e. while handler2 is being run because exception1 was raised, the
handler for exception2 should be handler3, not handler1; but it's
probably better to leave the general case undefined.  Also, it might
be nice to require the set of handlers to be set to the right thing
whenever a WITH-HANDLER is exited - so in

(with-handler
 (lambda ()
   (with-handler
    (lambda ()
      (call/cc
       (lambda (k)
	 (with-handler
	  (lambda ()
	    (k 3))
	  exception1
	  handler1))))
    exception2
    handler2)
   <expr>)
 exception1
 handler3)

when <expr> gets run after the continuation k gets invoked, the
handler for exception1 would be handler3, not anything else.  Or maybe
provide some separate function which insures proper behaviour at
certain locations even in the face of continuations.

Also, there are the issues of when exceptions would be raised by
functions and expressions defined in the standard, and just how the
user would get her hands on those exceptions.  Should there be
syntactic sugar to obviate the need of typing all those lambda ()'s?
And of course an entirely different method for handling these things
might be preferable...

david carlton
carlton@husc.harvard.edu