Arc Forum | EQ, EQL, EQUAL, ...?

Arc Forum

8 points by hilbertastro 6141 days ago | 8 comments

First of all, congrats on the release of Arc! It takes courage to put a new language out there and watch all the geeks rip it apart with their bicycle-shed-painting suggestions ;-P

One of the things that bugs me about ANSI Common Lisp is the huge set of "equality" predicates: EQ, EQL, EQUAL, EQUALP, ... It's nice to see Arc at least use a different name (ISO) that suggests "structural isomorphism" rather than the ambiguous concept of "equality." I imagine with the right type information, a compiler could convert ISO into a faster type-specific predicate (heck, even C compilers know to replace "==" with the right machine instruction, depending on the types of the arguments). I was a bit surprised not to see an advertisement along these lines in the Arc Tutorial -- something like, "Hey, we simplified the equality predicate system in CL!"

There's a famous paper somewhere about how the main reason CL needs both EQ and EQUAL is that an object's state is mutable; if you see "the same object" (via EQ) twice, it might not contain "the same data" (via EQUAL) each time. I've never encountered huge problems in my daily programming life because of this, though it might be nice to have some objects that are guaranteed immutable.

4 points by cje 6141 days ago | link

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

-----

6 points by pg 6140 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 6140 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 6140 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.

-----

3 points by fail 6141 days ago | link

"Hey, we simplified the equality predicate system in CL!"

How did they? (renaming EQUAL to ISO is not simpler..)

-----

1 point by dr_drake 6140 days ago | link

I think, by now, we can conclude that Arc is going to be an atavistic throw-back to early eighties hey-ho-lets-go hackery, where egg-heady concepts like immutable values and the implications of identity predicates have no place.

-----

3 points by cje 6140 days ago | link

Arc embodies just about every form of political incorrectness possible in a programming language.

-- Paul Graham, http://www.arclanguage.com/

He wasn't kidding, you see.

-----

4 points by serhei 6140 days ago | link

If I can easily understand what it does, and write all my programs with it, it's good enough for me.

</atavistic hacker>

-----