@StefanKarpinski , yes , I did read that paper: yesterday. Without going into details (would be too long here, better in a diff topic, let me know):
while the authors have a very strong argument for the usefulness of “egal” and it’s superiority over any other object comparison method they looked at, they fail at arguing that this “egal” does indeed match the intuitive and even philosophical notion of " object identity" (and I think they did try to argue that, in some first parts of the paper).
Me too; I don’t think changing a few words in how we interpret things changes the language. I’ll explain in a bit.
The way I see it, for ===,
First the types of
xandyare compared. If those are identical, mutable objects are compared by address in memory and immutable objects (such as numbers) are compared by contents at the bit level.
I said “definition” because it gives it’s “specification” (guidelines for implementation) . It is the only thing that precisely defines what === does.
Next, to associate any other name or description (like “same-ness”, “object identity” or “progr. indisting-lity”, etc) to this ===, there are 2 options:
- Argue that the meaning of that name is equivalent to, or follows from, the specification of
===above.- For that, of course, that name/description must have an intrinsic meaning , that would exist even if
===did not exist. Otherwise, it’s circular reasoning.
- For that, of course, that name/description must have an intrinsic meaning , that would exist even if
- Define that name/description based on the specification of
===.- Now here the authors may want to be a bit caregful: if users already have a strong meaning associated with that name/description, there will always be some resistance or friction or confusion, if the intrinsic meaning of that name/description conflicts with the meaning of
===as given by the specification.
- Now here the authors may want to be a bit caregful: if users already have a strong meaning associated with that name/description, there will always be some resistance or friction or confusion, if the intrinsic meaning of that name/description conflicts with the meaning of
“Programmatic indistinguishability” is the case of 1. above: provided that indeed Julia programs cannot (in reliable ways ) distinguish 2 objects for which === reports true, then I don’t see any contradiction or problems.
I think: “Object identity” and “same-ness” of 2 objects , on the other hand, is a case of 2. above. And they fall prey to the issue of conflict of meaning.
I can argue that the specification of === actually agrees well with the intrinsic meaning of “object identity” for muttables, but not for immutables (and this half-agreement is what enhances the confusion a bit). That argument again would require a separate topic; for now, take it as just an opinion. (If people want to see that argument, let me know, again in a diff topic).
So, the authors have a choice:
- go ahead, like most/all other prog. languages, and say: “this is how WE define object identity or same-ness, and how we are going to talk about it (like it or not).”
- don’t define “obj identity” based on
===specification. As I explained earlier, Julia (or other langs) don’t have actually to define “object identity” or “sameness” at all. If another name for===, is needed, pick one as innocent as possible (almost lacking other meanings) like: “more_equal”, “deep_equal”, “equal2”. Your choice.
Ex: “"this"and"this"are deep_equal.[0 0]and[0 0]are not deep_equal”. If users ask what that means, tell them “programs cannot distinguish them” or just send them to the specification of===I quoted above.
With option 2. , it’s not a new programming language, IMO. It’s just clearer interpretation of the language: avoid confusions, while still staying precise.