SELECTQ using = or EQ

[Robert W. Kerns <RWK at MIT-MC>]

    Date: 17 July 1981 17:31-EDT
    From: Carl W. Hoffman <CWH at MIT-MC>
    Subject: SELECTQ using = or EQ
    To: GSB at MIT-ML
    cc: JONL at MIT-MC, ALAN at MIT-MC, BUG-LISP at MIT-MC,
	Steele at CMU-20C

	Date: 17 July 1981 16:02-EDT
	From: Glenn S. Burke <GSB at MIT-ML>

	The semantics of SELECTQ are leaning towards allowing "mixed types",
	and those of CASEQ requiring everything to be of the same type.
	"knowning" that everything is of the same type can help the compilation
	of such a construct where that matters (pdp10 maclisp, for instance).
	Elsewhere such a constraint doesn't hurt; you just use EQ all the time
	anyway.  Guy, are you there?  Words of wisdom?

    Sure, I understand the need for mixed types.  I use a construct called
    CASEQ-EQUAL when I need EQUAL comparison for a CASEQ.

    What I object to is changing the definition of a construct as a result of a
    "bug fix".  It is a completely different thing to propose a change to the
    semantics of SELECTQ or CASEQ, discuss it, and then implement the change.

    It's too bad, actually, that we're using the name CASEQ to mean CASE-QUOTE
    rather than CASE-EQ.  Most people assume it stands for the latter.

Carl, I think you must be slightly confused about what is happening here.
SELECTQ is what is being changed, not CASEQ, which has always been the
way it is.  And it is being changed to be more general.  The BUG being
fixed was that SELECTQ was not compatible with the LISPM one, i.e. it
didn't allow you to compare fixnums and symbols in the same SELECTQ.
CASEQ has always barfed when you give it a fixnum when it expects a
symbol, or vice versa.  This Maclisp-ism is the reason it wasn't just
called SELECTQ ... it ISN'T SELECTQ, and never has been.  So if you've
been using them interchangably, you've been laboring under a misconception.
This distinction has been widely advertised.