EQ vs EQUAL: catch/throw performance loss

[JonL.pa@XEROX.ARPA]

I like your rationalization of this: ". . . Catch tags are supposed to
be symbols.  We generalized it a bit beyond that, because we could do
this at *NO* extra implementation cost and it made some odd cases a bit
cleaner . . .".  This would permit a random list cell to be a catch tag,
but the THROW primitives would not be required to call EQUAL.  The call
to use EQL would make more sense if it were a call to use EQUAL, because
fewer exceptions would have to be remembered, but then the cost factor
would come in to play again.

An underlying problem, however, is the deeper one of EQ semantics, and I
don't feel it is as bad as has been generally portrayed.  Namely,
contrary to the prevalent proverb, EQ does work on numbers, and a user
can in fact so use it.  What a user must understand is the more
complicated semantics of EQ as opposed to EQUAL -- a burden placed upon
him from the very beginnings of LISP 1.5.  Here's a simple paraphrase of
the problems in Common Lisp which he must understand:
  (1) two instances of a symbol FOO might not be EQ if they are interned
on
	different packages, or if at least one of them is uninterned. [so what
	is the identity of a "symbol" then? one would like to define it with
EQ,
	but one cannot ignore that english language communication typically
defines 
	it by the characters of its pname, which is why one would would have to
say,
	e.g., "ess-eye-colon-FOO" if the package distinction were important].
  (2) two instances of any heap-consed object will not be EQ unless
stored at the 
	same address; while the notion of "address" isn't really
machine-dependent, 
	the notion of when one has two EQUAL but not EQ objects is very program
	dependent, and there are very few constraints upon documented Common
Lisp 
	functions to preserve EQness.
  (3) the compiler may, at its discretion, convert a pdl-allocated
object into
	a heap-consed one of the same form (i.e., they must be EQUAL).  So you
have
	to know the potential range of pdl-allocation of your particular
implementtion.
  (4) numbers aren't the only objects with EQ problems due to
pdl-allocation; 
	although I don't remember if the Common Lisp manul comments on this
question, 
	it has been true for a long time that the MIT Lisp Machine descendents
do 
	pdl-allocation for the &rest argument to functions, and don't protect
against 
	this quantity being pointed to by heap structures.  Thus even a program
which 
	is itself free of updatings could find itself with two items which are
EQ 
	but not EQUAL! [the "two items" here are not two program variables, but
the
	same program variable at two different times].  I suspect that a simple
bit of 
	compiler technology is called for here.

-- JonL --