Arc Forumnew | comments | leaders | submitlogin
4 points by cje 6171 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 6171 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 6171 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 6171 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.

-----