Issue EQUALP-GENERIC

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

For the record, I oppose making generic any CL function in this
standard.

The fact that DOCUMENTATION and DESCRIBE are generic is perhaps a bad
precedent, but those are mostly used interactively or in `tolerant'
applications anyway.

I side with those who think the issue genericity is an appropriate thing
for a successor standard to study (based on the results of individual
implementations' experimentation).

My principle reason is that I think that making something generic
doesn't necessarily solve the problems it looks like it solves. It seems
to appease those who don't look at it deeply, making them go away and be
quiet because they think they can just go around changing methods
willy-nilly.  In fact, though, I think we need to develop some rules
about redefinition, shadowing, and even about documenting protocols
before we can successfully make generic anything which is going to
undergo a heavy pounding. And I don't think we yet have the wisdom to do
any of that.

By the way, I expect the ultimate "wisdom" we do evolve to have rules
against saying things like "the details of how this is done are not 
specific" and to require you to have a nice, clear abstract protocol.
I don't think you can write serious code that uses EQUALP without it.

I think people who use EQUALP should do so because they (a) recognize
it to be arbitrary and (b) like that particular arbitrary definition.
I think anyone else should `roll their own.'

If you were able to describe EQUALP in a more abstract way, I would not
oppose you writing an implementation-specific generic function protocol
for your implementation and proposing it (with the results of your years
of testing) for the next standard.