Condition System Rewrite

[Richard P. Gabriel <rpg@lucid.com>]

I have just completed my first pass rewrite of the condition system
chapter. While doing this I noticed some omissions. I wonder whether
we need to go to X3J13 to fix these or whether we can simply add the
right stuff. 

First, the precise order of search for handlers is not specified. It
states that a dynamically inner handler-bind, for example, establishes
handlers that are more specific than outer ones, but there is no order
specified within a handler-bind. Because the order matters only when
two handlers apply to the same condition, I suggest the rule be the
same as the class precedence list order. When handlers simply return
values and hence keep invoking the next one, this is simply
call-next-method order. Pitman's code finds the first one that applies
within a cluster according to the order they were pushed onto the
cluster. I think this is wrong. He also punts the cluster if the handler
simply returns and searches the next one. His comment on this line of
code is

	(return nil) ;?

I think this is wrong. Lucid continues within the cluster, but in the
same random order as Pitman's code would if the (return nil) were
deleted. Better, but still wrong.

It is not specified what happens if handler-bind supplies two handlers
for the same type. Same for handler-case.

It is also not specified what happens if restart-bind supplies two
restarts with the same name (nil doesn't count). Same for
handler-case.

I suggest ``unspecified'' for what happens in these cases.

Kathy, I need another day or so to proof my draft, then I'll let you
have a gander.

			-rpg-