KMP's proposal

["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>]

    There seems to have been a disappointingly small amount of discussion of KMP's
    proposal, unless some of the mail isn't getting to me.  I think I got two messages
    from Scott Fahlman, two from Mary Fontana, and one that I sent myself.

That's all the mail I've seen as well.  Perhaps the problem with FTP-ing
the proposal from CMUC deterred people from commenting, but that should
be fixed now.  If anyone has any strong reservations about this kind of
approach (as opposed to the small details), you'd better speak up now,
or else the three or four of us who are interested in this issue will
wind up settling it among ourselves.  (Maybe that wouldn't be so bad.)
Once we've got a proposl that those of us on this list like, we should
send it to the full Common Lisp list, and if nobody objects then, we can
take it as a probationary standard, I think.

    Incidentally, in my proposal analogous to KMP's (from long long ago) I think
    that the arglist to SIGNAL (and SIGNAL-CASE, ERROR, CERROR, and WARN) was
    allowed to be an arbitrary arglist, defined by DEFINE-SIMPLE-CONDITION, rather
    than being forced to be &KEY; the advantage to this is increased brevity for
    conditions that have a small number of parameters, or whose parameters consist
    entirely of a format-string and arguments formatted by that string.

I'd prefer to go with all-keywords for uniformity, but since the user
would have to know what a given condition expects in any event, I could
live with Moon's proposal.

    You need both DEFINE-GLOBAL-HANDLER and UNDEFINE-GLOBAL-HANDLER (I think
    CONDITION-SETQ is an unclear name).  We have these but don't have enough
    experience with them yet to consider proposing them to go into a simple
    stripped-down thing like KMP's.

That name change is fine with me.  I think we'd better put these in
right from the start, since it looks to me like certain applications
will have to go through confusing gyrations if we leave them out.

    I agree, except that the handlers established by any one condition-bind should
    be tried in the order that they were written.

Sounds OK to me.  We might want to warn users that unless they are doing
something odd, they will want to put the more specific handlers before the
more general ones when they write a condition-bind.

Has anyone got time to write up a revised proposl including the changes
suggested by Fonatana and Moon, suitable for incorporation into the
manual?  I will do this if nobody else wants to, but I'll be off the net
starting next Saturday until August 4, so I can't work on it before then.

-- Scott