Arc Forumnew | comments | leaders | submitlogin
Doubt about 'is' operator
3 points by 6502 2928 days ago | 11 comments
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...


1 point by rocketnia 2928 days ago | link

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.

-----

1 point by akkartik 2928 days ago | link

Hmm, I hadn't considered renaming iso to is. wart still calls it iso; is no longer exists. (Since it's built atop Common Lisp you can just use eq when you truly need it.)

I like the name iso. is raises philosophical questions about what makes two things equal. iso neatly sidesteps them by evoking the precise image of structural equality.

---

The original discussion that led to the id idea: http://arclanguage.org/item?id=13690

-----

1 point by rocketnia 2928 days ago | link

"Hmm, I hadn't considered renaming iso to is ."

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.

-----

1 point by Pauan 2928 days ago | link

But but but, `is` is one less character! :P

https://convore.com/arc-runtime-project/rename-acons-to-cons...

-----

1 point by _6502_ 2926 days ago | link

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...

-----

1 point by Pauan 2928 days ago | link

Indeed. I plan to change `is` in Arubic. Though it also seems like a good idea to replace `is` with `iso` and use `id` or something for identity checks, as already mentioned in this thread.

In fact, in Arubic I plan for strings to just be a special subtype of conses, so you can use car and cdr on strings, and all operators that expect conses should work on strings as well.

-----

2 points by rocketnia 2928 days ago | link

"In fact, in Arubic I plan for strings to just be a special subtype of conses, so you can use car and cdr on strings, and all operators that expect conses should work on strings as well."

Can you set the car of a string to an arbitrary value, like you can with a cons? Is "" nil?

I'm not trying to change your mind, but "all strings are conses" is the kind of thing lots of people think would be nifty only to change their own minds later. :)

-----

1 point by Pauan 2928 days ago | link

"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.

-----

1 point by rocketnia 2928 days ago | link

Okay, sounds fine to me. ^_^

-----

1 point by Pauan 2928 days ago | link

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.

-----

1 point by aw 2928 days ago | link

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).

-----