CASEQ with no T clause

[GLS at SU-AI (Guy Steele)]

I recommend that a CASEQ which "falls through" not return NIL,
but give an error and recycle with the new thing returned from
the error.  This may seem like a throwback to the days when a
COND which fell off the end (*except* in a PROG - what a kludge!)
was likewise an error.  However, I suggest that if a CASEQ falls
off the end, it was more likely the result of an unanticipated bug,
giving it something it could not handle.  Thus I would have CASEQ
expand into something like:
	(PROG (GNARDS)
	      (SETQ GNARDS THE-THING)
	 BARF <THE-MOBY-COND>
	      (SETQ GNARDS (ERROR '|X{BULLET,DUST,BAG}: CASEQ BIT X|
				  GNARDS
				  'WRNG-TYPE-ARG)))  ;UNSEEN-GO-TAG ??
or, pseudo-equivalently:
	((LABEL PHROG
		(LAMBDA (GNARDS)
			(COND <CLAUSES>
			      (T (PHROG (ERROR ... GNARDS 'WRNG-TYPE-ARG))))))
	 THE-THING)
depending on whether you prefer a statement-style or functional-style
approach.  In any case, I find that *most* CASEQ's I write want to have
this kind of error recovery loop wrapped around them, and it's a pain to
have to write each one out explicitly.

A related idea, which I have seen in some Algol-like proposals (SIGPLAN
Notices?  but I can't locate a reference), is a kind of statement called,
say, CASEGO; it effectively recognizes that CASEQ clauses are "labelled"
in a manner similar to PROG statements, and provides a way to go to
a specified clause by mentioning a "label":
	(CASEQ A-FIXNUM
	       ((0 4 6 8) (HACK-EVEN))
	       ((1 9) (BORING))
	       ((3 5 7) (MUNCH-PRIME))
	       ((2) (HACK-EVEN) (CASEGO 3)))	;2 IS ALSO PRIME
This is semi-ransom, though probably not all that hard to compile
or interpret.  I brought it up only because the first problem has
a solution expressible as:
	(CASEQ the-thing
	       ...
	       (T (CASEGO (ERROR ... the-thing 'WRNG-TYPE-ARG))))
CASEGO as such doesn't excite me - it's just random.  But the first
problem deserves some thought.

-------