[no subject]

[Kent M. Pitman <KMP at MIT-MC>]

    Date: 4 December 1980 05:32-EST
    From: Jon L White <JONL>

    ... Really?  Works for NO ONE??  I tested it out for all the previous 
    cases and encountered no bugs.  You obviously didn't test out your buggy 
    version for the one explicit example I had sent you, namely `(A . ,b .)
-----
My comment in the code when I made the original change said that `"FOO" had
been previously broken. If `(A . ,b .) was working then it obviously wasn't
hitting the (BREAK |+ibx-uhunkp/||) which `"FOO" was hitting. Hence, I 
couldn't have broken anything with my change, while my first patch was 
obviously broken by your rewrites.

The point is not the bug -- the point was the nature of it. Specifically,
random BREAK's in the middle of released code followed by no correction code
for people that $P, strike me as a *REALLY* bad idea. I think that if you want
to put a breakpoint in released code it should definitely not say just
PSZ-LOSES or +ibx-hunkp| -- it should do something like:

	(DEFUN +INTERNAL-LOSSAGE (CONTINUABLE FUN TAG VAL &OPTIONAL (DATA ""))
	   (FORMAT T ";Lisp internal function ~S is buggy.~@
		      ;Please report this to BUG-LISP.~@
		      ;Location-ID: ~A~%;Value(s): ~S~%~A"
		   FUN TAG VAL DATA)
	   (COND (CONTINUABLE
		  (*BREAK T "LISP-BUG (Typing P might win)"))
		 (T
		  (ERROR "Error not proceedable" FUN 'FAIL-ACT))))

	(DEFUN |+ibx/|| (X) ... (+INTERNAL-LOSSAGE () '|+ibx/|| 1. X) ...)

Ie, if you have reason to believe that a function is buggy, then tell the
user that it's not his fault, tell him how to send you mail, and what 
information he should provide, and tell him if P'ing is going to have a 
chance of recovering. (A primitive function in Lisp that did something like 
this might be worth the space.) But please don't just put in random BREAKs.