[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

EQ vs EQUAL: catch/throw performance loss

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
	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
	but one cannot ignore that english language communication typically
	it by the characters of its pname, which is why one would would have to
	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
	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
	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
	to know the potential range of pdl-allocation of your particular
  (4) numbers aren't the only objects with EQ problems due to
	although I don't remember if the Common Lisp manul comments on this
	it has been true for a long time that the MIT Lisp Machine descendents
	pdl-allocation for the &rest argument to functions, and don't protect
	this quantity being pointed to by heap structures.  Thus even a program
	is itself free of updatings could find itself with two items which are
	but not EQUAL! [the "two items" here are not two program variables, but
	same program variable at two different times].  I suspect that a simple
bit of 
	compiler technology is called for here.

-- JonL --