Stavros wrote:
>This :test #'eq nonsense is really getting on my nerves.
How right you are! No matter on what side we stand :-)
>The funny thing is that in over 75% of #'eq cases, either the
>tested-member was a symbol, or the list was a quoted list of symbols,
>so a competent compiler would have required no explicit :test clause
>at all, choosing eq automatically since for symbols it is equivalent
>to eql and is more efficient. (Do any of our standard compilers handle
>this case correctly?)
Well, I converted the uses of memq to member :test #'eq just
because that is the semantically equivalent thing (it is how memq
is defined) and I didn't want to change the semantics!
Indeed, cmucl and sbcl do the right thing for tests on symbols
and use an #'eq test even if not specified explicitly bit I am not
sure what other compilers do. In fact you could always use the
standard #'eql test without changing the semantics in the case of
symbols, but it might be slower with some compilers, that are not
as good as cmucl or sbcl. So if you are disturbed by the
explicitly specified test you can always just remove it.
>Oh yes, and there was one case with a carefully inserted eq-test which
>was incorrect -- it should in principle have been an eql test (I don't
>think that CL guarantees that (eq 0 0) = t).
Yes you are right, CL does not guarantee eq on numbers (usually it
is ok with fixnums, but there is no guarantee). But I did *not*
change any test in converting form memq to member, so obviously
that test was already wrong before - and memq would certainly not
be the right thing then!
What would be gained by changing back to memq? Absolutely nothing!
So I am opposed to that and certainly am not inclined to do it
myself.
Andreas