What is the rationale of having 'is' operator telling two lists with the same elements are different, but that two strings with same characters are the same? Given that strings are mutable I don't see the reason for this asymmetry...
Yeah, I see it as a poor design for 'is. Personally, I pretend strings are immutable, if only so I can use 'is without regret.
The fact that Arc's 'testify and 'case rely on 'is might be part of it. I and akkartik believe everything should be using 'iso whenever possible instead, and I think akkartik goes as far as to say that 'iso should be named "is" and 'is should be dealt with some other way. There was a recent discussion about replacing today's (iso a b) and (is a b) with (is a b) and (is (id a) (id b)) respectively, and that seems like a pretty nice idea.
Oh, oops. Sorry! XD I guess I figured that the name 'is is so good that something oughta use it. And for some reason, I'm not currently concerned that the name "is" should be restricted to the most picky kind of equality operator (as I was in that thread).
"iso neatly sidesteps them by evoking the precise image of structural equality."
Right now, I don't believe the purpose of 'iso is very precise either. I think a type's designer should extend 'iso with whatever makes intuitive sense for that type, just as long as it's still an equivalence relation. Guess I'm in an informal mood.
Mutable strings are indeed sort of "strange", especially given Lisp semantic for literals that is different for example from Python (in python the syntax "[1,2,3]" is a list literal, but is indeed equivalent to Lisp "(list 1 2 3)" and not to "'(1 2 3)", i.e. returns a new fresh list at each evaluation). Mutable literals is somewhat counterintuitive and in Python a similar problem happens with default values for parameters (i.e. "def foo(x=[1,2,3]):...") not because the literal is altered but because default value is evaluated only once at function definition time. This idea that what is in the program text is not in this case fixed is a trap in which newbies often fall...
"Can you set the car of a string to an arbitrary value, like you can with a cons? Is "" nil?"
Yes and yes. I plan for the only difference between strings and conses is that A) they have a type of 'string, in addition to a type of 'cons, and B) they display differently, surrounded by "" rather than ()
Generally speaking, strings will only contain characters (since that's what the string constructor does), but I don't see why they can't contain arbitrary stuff, if you want to do that.
P.S. I might not actually give them a type of string... in that case the only difference would be that they display differently. That might be an interesting approach.
Actually, you probably didn't notice, but in Arubic/Python, strings literally are a subclass of cons, so they really do behave just like conses in almost every situation. I didn't make (is nil "") return t though. That shouldn't be hard to add, but I've been busy on Arubic/ar.
A rationale (which people may dislike or disagree with) is that we might like to have the short, easy to type version of an operator perform the most common operation that we typically do on each type (even if it isn't logical).
If so, we'd also probably want a more specialized, longer named version of the operator that does the precise operation such as checking for object identity for all types (which we currently don't have in Arc without dropping into Racket).