Arc Forumnew | comments | leaders | submitlogin
4 points by cje 5103 days ago | link | parent

It's not really any "simpler" -- pg just picked two (EQ and EQUAL) and ignored the others.

6 points by pg 5103 days ago | link

The is operator isn't quite eq. For strings it behaves like equal, because that's how one tends to use strings.


1 point by hilbertastro 5102 days ago | link

I usually don't directly compare strings for (character-wise) equality; I search for substrings or regexes, parse out data of another type, or compare modulo case. Strings are just sequences to me; I don't have a reason to process them differently than any other kind of sequence, unless I'm working in C and have to use strings as a hacked-up replacement for symbols. That being said, other languages have chosen to make strings a "value type" (e.g., C++'s std::string).

Thanks for clarifying! From what I've read on CL over the past 3-4 years, EQ/EQL/EQUAL seems to be one of the outstanding issues. (People also complain about the lack of extensible sequences (though some implementations may offer this) and a few things about CLOS. Well, they complain about _everything_ but usually don't offer to fix anything ;-) .)


2 points by cje 5102 days ago | link

Ah, right. Do hash tables work properly with strings, then? I've had CL hash tables with :test #'equal, which always seemed annoying to me.