re: Issue: EQUAL-STRUCTURE (Version 5)

[Kim A. Barrett <IIM@ECLA.USC.EDU>]

I thought this had been pretty well hashed out, so I was surprised to find some
serious problems with the proposal.  While I support the general idea of the
proposal, I can't vote in favor of it in its current form.  If these things get
cleaned up, then I'll vote YES.  Note that all of my problems with the current
proposal have to do with EQUALP; I agree with the proposal for EQUAL, and would
vote YES for it as a seperate issue if the EQUALP stuff can't be resolved in
time. 

1. The description of EQUALP's behavior does not match CLtL, since it
references EQUAL more than it ought.  Specifically, characters should be
compared with CHAR-EQUAL, and numbers should be compared with =, while the
proposal says EQL for numbers (by defaulting to EQUAL) and is ambiguous about
characters (could be EQL (by defaulting to EQUAL) or CHAR-EQUAL (since string
comparisons are case insensitive)).

2. The proposal says EQUALP descends arrays, structures, and instances, but
uses EQ on other types, and gives hash-tables as an example of a data type
which is not descended.  What if, in a given implementation, hash-tables are
implemented using structures or instances.  Does this mean that such an
implementation must include code in EQUALP to explicitely prevent descending
into hash-tables (and presumably any other COMMON types which are implemented
using structures or instances)?  This question has to be answered if the use of
EQUALP is to have any chance of being portable when applied to such objects.