restarts and MI as possible omissions

[Kent Pitman <kmp@harlequin.com>]

[Recipients pruned.  I assume we're all on the main list.]

This reply is motivated by Dalton's message but is not directed
particularly at Dalton but more generally.

Dalton> However, it should be possible to design a condition system that
Dalton> makes sense both with and without restarts;

This is certainly true.  See my remarks below about MI.  The arguments
are similar.  To what I've written there I will add only this.  The
primary power that restarts provide are:

 (1) reflection -- since Scheme is not generally reflective, I regard
     restarts as a special little kind of reflectivity that allows one
     to ask about catch tags, not only in an "is it there" way but also
     in a "why is it there" way.  (I'm not sure even a reflective tower
     would let it do the "why" part, but I suppose it's possible.)

 (2) interactivity -- there is simply no way to substitute for the 
     failure to provide this information.  Of course, I'm sure that some
     Scheme designers think that one can just put off and put off the idea
     that Scheme needs to worry about users.  ("We'll leave users as an
     exercise to the user." I can hear them say.)  Well, all I can say 
     is that if you do this, you may indeed find that users are not an
     issue.  Frankly, interactive restarts is a very powerful tool, the
     use of which is immediately obvious to any user who has experienced
     them on a regular basis.  It transforms an all-or-none system into a
     system where the interactive user -- even an unsophisticated one --
     can finally make really interesting choices about what to do in what
     would previously have been a failing situation.  Sure, don't care if
     you want--you'll have no trouble keeping up with Unix.  But you're 
     losing a really major selling point for Scheme.

Both of these are issues of "protocol", not "primitive functionality",
but it is protocol that no single user has the power to establish, and
so protocol that will simply be lost if you fail to include it at the
language level.

Dalton> The Kelsey proposal would also be simplified if it could
Dalton> assume a standard way of doing records.  Multiple inheritance
Dalton> can probably be avoided.

I think this is a very good observation.

Sadly, it doesn't speak to the goodness or badness of multiple
inheritance or of condition systems, but rather the willingness of the
group to embrace a long proposal.

I'm sure there are some in our midst would say "No, that's not it.
The issue is that these should be considered SEPARATELY."  But the sad
truth is that I'm sure when considered separately, the separated
multiple inheritance proposal will die because it's "just too radical"
for some of the conservatives among us.  (I bet the USERS would have a
different point of view, btw.  But they have no serious voice among
us.)  So what I see is not Kelsey refusing to see that these issues
are separable as much as I see him saying "Here is something that
could make the system so much more useful and maybe if people see it
in context, they'll finally understand why it's important."  (I'm
reminded of the message we saw from someone in the CL design process
when the error system was discussed where they said "OHHHH.  Multiple
inheritance can be used for more than one thing.  And I thought it was
only useful for window systems."  Good examples may be hard to come by,
but that doesn't mean that the idea isn't good.  It may take making it
available to users before they show you the things you overlooked about
other ways you could take advantage of it...)  So if what we hear is
"these should be separate proposals" let's listen carefully for the whisper
of "so we can kill the second".  

The original Common Lisp condition system was written and adopted
without multiple inheritance and the two were only later reconciled
when CLOS was adopted.  There was a little bit of trouble at the seams
because people were never quite sure that CLOS was there to say or how
deep they wanted conditions to get intermeshed, but the problems were
mostly with the individual personalities of committee members and not
with the underlying theory.  But I think that won't happen to Scheme 
(not because it doesn't have "personalities" to deal with but because
I think those "personalities" will assure we'll never have multiple 
inheritance).

So maybe it would be the better part of valor for Richard to
voluntarily make his system seriously less useful (i.e, remove any
mention of MI) in order to have it qualify as a proper candidate for
inclusion in Scheme.

Still, I recommend that he hold firm on restarts, and even the
interactive part of restarts because if it doesn't at least have some
lingering value, there's little point in even discussing it.

If we get a condition system with no restarts, you can expect me to
refer to it frequently in public forums as labotomized, not merely as
an emotional term but as a technical description, since it will have
undergone the forced and unnatural removal of a major component of its
ability to reason usefully...

It's not like coming up with a useful restart system involves years of
funded research; and it's not like there is a single canonical system
we will all eventually converge upon.  It's simply the case that we
need to agree to agree for once, instead of agreeing always to
disagree, and move ahead. This is just a matter of seriously useful
functionality being poo-poo'd by those who think its absence will make
either no serious difference or a net gain to the Scheme community.
And I'm really quite sure they are wrong.  Restarts belong in the 
language.  Their absence in other languages is not proof that they are
unnecessary, it is simply a manifestation of the old saying "ignorance
is bliss".