More about proposal

[Steven <Handerson@CMU-CS-C.ARPA>]

I've been reading the Symbolics documentation and thinking about proceed types.
The criteria a proceed type may use to determine whether it can proceed or not
may not be simple.  I haven't the experience to give an example, but the idea
of passing a list of the usable proceed types sounds forced.  Ideally, a
proceed type should be able to decide itself, based on the condition object and
any other environmental information it can determine.  [It can look for itself
in a supplied list of proceed types, if it wants.]

I propose a notion of an operation @i(failing), which can basically be
implemented as the operation's function returning some special value.  If an
operation fails unexpectedly, it's a bug, and the system invokes ERROR.  If the
operation was invoked using a special catching form, the handler can cause an
expression to be evaluated instead.

Does anyone have any comments whatsoever on my proposal so far?  If you think
it's too simple, we're only in the error-handling business, not programming in
general.  I agree it's slightly messy as stated, but a little attention might
smooth out the rough edges.  The slowest part in relation to a Flavors
implementation will be the assoc list of instance variables, and I don't
anticipate enough of them to make much of a difference.

-- Steve