Arc Forumnew | comments | leaders | submitlogin
2 points by akkartik 4421 days ago | link | parent

Thanks for all that detail! Yeah, using lists and hashes as hash keys is kinda crazy. And mutating such hash keys is utterly crazy.

I think the crux is this: "..it is possible to distinguish two mutable objects by mutating one of them and checking to see if the same change occurs in the other object."

This still feels like a crazy abstraction. If two mutable objects look the same I want equality to say they are the same by default, not go into contortions to cover its ass because I might choose to mutate them and I might then care about reference equality.

However I have a lot more respect after your comment for how egal can simplify lots of thorny concurrency issues.



2 points by rocketnia 4421 days ago | link

This is a matter where Pauan and I agree on the ideal semantics completely. I seem to remember us advocating egal a few other times (though I don't think I've ever called it "egal").

That said, I don't care if this functionality is provided as a two-argument function or as (addr ...).

---

"Yeah, using lists and hashes as hash keys is kinda crazy. And mutating such hash keys is utterly crazy."

I built Cairntaker on the idealistic notion that every single first-class value is a mutable or immutable weak table. That includes the table keys. Cairntaker does make compromises for performance and FFI, but none that betray this ideal.

Even when I'm programming normally in Arc or JavaScript, I use tables with immutable list keys all the time. It doesn't seem unusual to me.

-----

1 point by Pauan 4421 days ago | link

"This is a matter where Pauan and I agree on the ideal semantics completely."

Quite the rare thing indeed.

---

"I seem to remember us advocating egal a few other times (though I don't think I've ever called it "egal")."

I personally haven't. I only recently started to actually care about egal because of Nulan using immutable objects.

I do remember us having discussions before about making "iso" the default equality in Arc, which is what wart does, but I don't recall us talking about cons mutability.

-----

1 point by rocketnia 4421 days ago | link

"I personally haven't."

Oh, well then welcome to the club. XD

I looked around for where I talked about this before, and I guess I was mainly thinking about this time: http://arclanguage.org/item?id=13701

I touched upon it in at least one other conversation after that: http://arclanguage.org/item?id=14596

However, I can't find any more than that. Maybe I just took it for granted at that point.

It is the policy I applied in Cairntaker. Cairntaker interns all immutable tables so they can be compared for deep equality even after some of their entries have been garbage-collected. Equality support is essential in Cairntaker since any value can be used as a table key.

-----

1 point by Pauan 4420 days ago | link

"Even when I'm programming normally in Arc or JavaScript, I use tables with immutable list keys all the time. It doesn't seem unusual to me."

You silly. Neither JavaScript nor Arc have immutable lists. Well, I guess you could use Object.freeze on an array in JS, but... even if you did that, it would just serialize the array to a string.

-----

3 points by akkartik 4420 days ago | link

Ha, here rocketnia is on my side! I don't need permission from racket or arc or javascript to make a list immutable. I just have to not modify it!

-----

2 points by rocketnia 4420 days ago | link

Lol, yep. The way I "implement" immutable lists in practical programming is by not modifying them. I rationalize that their static type would enforce this if only there were a type system. :-p

More specifically...

In Arc I can't really rely on using lists as keys, since (IIRC) Jarc converts table keys to strings using the same behavior as 'write. However, in practice I have used lists of alphanumeric symbols, since those have a predictable 'write representation on Jarc, a predictable Racket 'equal? behavior on pg-Arc, etc.

Similarly, in JavaScript I tend to use Arrays of strings, storing them as their ECMAScript 5 JSON representation.

  myTable[ JSON.stringify( k ) ] = v;

-----

2 points by akkartik 4421 days ago | link

Yeah I take that back about immutable list keys :)

This is all most interesting. I'm going to keep an eye out for nice programs that exploit structural equality on mutable structures. Y'all should do the same!

-----

1 point by Pauan 4421 days ago | link

"This still feels like a crazy abstraction. If two mutable objects look the same I want equality to say they are the same by default, not go into contortions to cover its ass because I might choose to mutate them and I might then care about reference equality."

Then make the objects immutable. Then equal makes sense. Then the compiler/interpreter knows what your intent is. Then you avoid all these issues. Then you don't even need a distinction between eq/equal: you can just use egal.

This seems to me to be the obvious choice, but it seems we disagree.

-----

1 point by akkartik 4421 days ago | link

Yeah, I didn't fully understand egal when I said I agreed with it if the language distinguishes immutable objects. I want my equality to be more lenient in comparing mutable objects. Even with mutable objects it seems a lot more common that I just care about structural equality rather than identity.

-----