Stability?

[Kent M Pitman <KMP @ MIT-MC>]

    Date: Tue, 13 Nov 1984  00:22 EST
    From: Skef Wholey <Wholey at CMU-CS-C.ARPA>

    It seems that if X is implemented as specified, but X is subject to debate,
    then the specification of X should not change.  Some people are making 
    appeals to taste, but there are other less tasteful features of the
    language that no one's trying to change.

The issue of THROW using EQ or EQL is a discussion of what happens in the
undefined case of using a number or character. EQ and EQL are the same over
the defined range of args, and whether the words are explicit here or not,
the clear implication is one of "is an error", and we have left "is an error"
things open to discussion.

    Should CMU and DEC and Data General and Symbolics and whoever else 
    out there be forced to reimplement something because it's not as
    tasteful (in someone's opinion -- not everyone's) as could be?

No one has ever been forced in these discussions to do a particular thing.
The point of putting thoughts on the floor is to find out what consensus is.
I actually believe it is critical that we re-examine certain issues in the
aluminum issue, with the aim of changing them in later editions, even if such
editions don't come soon. Not every decision made in the first edition was
the right decision, and we cannot force users to live with all mistakes 
forever. A major purpose of any further discussions on this list must be to 
figure out where we've made mistakes and what subset of those it would be
possible/appropriate to correct.

    Sure, the compiler could easily figure out where an EQ-Throw could be used.
    I'll go and fix our implementation if everyone thinks I should.  But 
    that's not my idea of a stable language specification.

Why not. No working program will break? Formerly undefined programs will 
become well-defined. There is nothing even remotely unstable about such a
change. All changes should be so stable!

    Hey, why not have Throw take a keyword argument for the test to use?  Or an
    abitrary predicate that the tag must satisfy?  Other keyword arguments 
    would be useful as well...

       (unless (throw *zinger* 'hi! :test #'equalp :if-does-not-exist nil)
         (format t "Catch tag ~S was not found.~%" *zinger*))

I actually had what I think was a reasonable application for a :TEST arg
recently. If you're being serious, I'll be glad to explain why it would 
be useful. This, by the way, is also a "stable", upward compatible change.

I also like the :IF-DOES-NOT-EXIST key, actually. In Maclisp, I have seen 
a few applications for (LET ((ERRSET NIL)) (ERRSET (*THROW ...) NIL)), 
which accomplishes the same end. It saves having to do
 (DEFVAR *FOO-TAG-AVAILABLE* NIL)
 (DEFUN F ()
   (*CATCH 'FOO
     (LET ((*FOO-TAG-AVAILABLE* T))
       ...)))
 (DEFUN G () (IF *FOO-TAG-AVAILABLE* (*THROW 'FOO *SOMETHING*)))
which just wastes a lot of verbiage. Its only problem comes in a breakpoint
where you might want to bind *FOO-TAG-AVAILABLE* to NIL, but you can't.
There would have to also be an accompanying way for breakpoints to hide
pending catch tags.

-kmp