Re: restarts and MI as possible omissions

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

Alan Bawden wrote:

> 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!

That is the sort of thing I had in mind by saying that MI was not 
the only way to express that "recovery strategies for several types
of conditions might be appropriate for a particular exceptional
situation" (which is what Richard Kelsey said made MI necessary).

What you describe can be seen as MI, true, but it's not what people
will expect ...

You probably didn't intend this as a proposal -- that a condition be
respresented by a list of symbols -- but I think it's instructive to
treat it as one.

I would expect at least the following objections (probably from
different people):

  * Even it we adopt the basic idea, conditions should be records
    that contain, in some field, a list of error types (or whatever
    we call them).  Having conditions just _be_ such lists is too
    limiting and insufficiently abstract.  [We we're back again to
    the questions of records, inheritance, and object systems.]

  * _Symbols_ (and indeed pairs) should be separable from the language
    (something that could be provided by a library) rather than wired
    into the language in various ways.  Even though we might imagine
    the condition system as a library, it would be required by so
    much else that it would still make symbols too essential.

  * In ML, ...  (^_^)

  * The condition proposals don't feel sufficiently
    "Scheme-like".  I don't think to myself, when looking at them, 
    "yes, this is just right for Scheme".  Instead, I think "that
    would be useful and it's not too complex", or something like
    that.  And when none of the proposals on offer seems "right",
    it's hard to decide between them.

This is a relatively small issue: how conditions are represented;
and other proposals are likely to raise just as many objections.
I think it's very unlikely that the Scheme community can agree
on a condition system, or even on a significant part of a condition
system, or indeed on any other substantial change to the language.
We managed to get macros, just.  We might, maybe, get records
as distinct types.  But I think that's about the limit of what we
can expect.

Kent Pitman wrote:

  But I also want to see the community come together on this.  The
  more you leave these as an exercise to the community, the less the
  community can ever "move on" beyond these issues to other, more
  interesting ones.  You condemn every user to having to spend time
  shopping for and comparing systems, when it's time we as designers
  did that.  Now nearly 20 years after the invention of Scheme, it is
  time to stop talking about whether exception systems or multiple
  inheritance systems are a good idea.  It's time to either get our
  act together and pick one we can all live with, or to admit that
  we're just deadlocked.

If we look at the development of a number of languages, including
at least Scheme, Common Lisp, EuLisp, and Dylan, we find that some initial
agreement or enthusiasm for the new lenaguge gets things to a certain
point, and then further developments become much more difficult.  For
a while, people can agree even on substantial issues where there isn't
a single, clearly best answer and where there are "standard arguments"
both for and against.  Later, for similar issues, agreement proves
much more difficult to obtain, and the standard arguments are
repeated again and again, without resolution.

Common Lisp managed to get amazingly far nonetheless, because a
pragmatic attitude usually prevailed and because decisions were made
by voting.  That way you get decisions, though they don't always form
an elegant whole.  But even then there were a number of cases where
the agreement was to leave something unspecified.

-- jd