restarts and MI as possible omissions

[Alan Bawden <Alan@lcs.mit.edu>]

   Date: Thu, 18 Apr 96 19:09 EDT
   From: Chris Hanson <cph@martigny.ai.mit.edu>
   ...
   And what is really scary is that the discussion hasn't even touched on
   the condition-type taxonomy, and the guarantees given to the
   programmer as to when particular conditions will be signalled.

Bingo.

Personally, I don't care very much about the details of how a condition is
signaled.  I can pretty much live with every proposal I have ever seen on
that aspect of a condition system.  Restarts?  Sure, they're useful, but I
could also live without them.  The algorithm for finding a "handler" for a
condition?  The details really don't matter as long as it basically works.
I can pretty much trust most of you guys to design this part of the
condition system right.  I'm sure it will be fairly small and elegant.

Unfortunately, that part of the system is totally useless to me until you
tell me exactly what happens when `open-input-file' fails to find a file.
I need to know what the standard, -portable- conditions are.  I admit it's
not very much fun to work on specifying what the standard conditions are,
and exactly when they happen, and what you can do in a handler for one --
it's much more fun to work on clever control structures -- but most of the
actual work is in specifying the conditions themselves.

And by-the-way.  I don't understand why people are so scared of a condition
system that has some kind of "Multiple Inheritance".  Hell, the Emacs Lisp
condition system is totally simple, but -it- supports multiple inheritance.
In Emacs Lisp a condition is a list of symbols, like 
`(error file-error file-already-exists)'.  You want a condition that
inherits from two other conditions?  Easy: form the union of the two lists.
See?  Multiple inheritance doesn't have to be scary!

(Actually Emacs Lisp uses a different terminology, but never mind...)