CASEQ and CHECK-ARGS

[GLS at SU-AI (Guy Steele)]

Ordinarily I would agree with you about using CHECK-ARGS.
However, CASEQ is a special situation:
(a) at the implementation level, what CASEQ is doing already
is to check a thing for membership in a set.  Doing the entire
test first with CHECK-ARGS is redundant.  This is particularly
bad if symbols rather than fixnums are involved.
(b) at the user level, it is a pain to have to enumerate the
valid elements twice, once in the CASEQ and once in the CHECK-ARGS
forms.
(c) given CASEQ with a loopback, you can very easily override
the loop with a T (OTHERWISE) clause; but given CASEQ without
a loopback, it is very clumsy to get the loop.

Thus, while I agree that CHECK-ARGS should be considered
the general mechanism for this sort of thing, the above
considerations seem to make it worth having CASEQ itself
have a check and loopback.  As I said in my original note,
UNSEEN-GO-TAG might be a more appropriate classification
than WRNG-TYPE-ARG anyway; while this is semantic hair-splitting,
such a classification would take CASEQ out of the purview
of CHECK-ARGS.
(I just realized that CHECK-ARGS may actually be spelled
CHECK-ARG - I forget.  If so, I apologize.)
-- GLS

-------