clarify which spec values do and do not carry identity

[michaelficarra]

In a recent PR, some found it valuable to call out the fact that Private Name values have identity. This got me thinking that we should be explicit (say, in 6.2 ES Specification Types) about which spec values have identity. I'm thinking that we could say that all spec values aside from a few have identity. The ones I can think of are (extended) mathematical values, primitive ECMAScript language values, sequences (as in code points for source text and code units for strings), and spec enum values. There are some types, such as Data Block, which have complex identities, and which confuse identity and equality.

Values that have identity should be referred to as "a"/"an" (an empty List) and constructed using "a new" (a new List). Values without identity should be referred to as "the" (the empty string) and not constructed, just described.

We can then audit that we're not doing things like assuming structural comparison for things that have identity.

[jmdyck]

How would you define "identity"? What's the normative effect of saying that a value does or doesn't have identity?

[michaelficarra]

@jmdyck When values of a spec type have identity, another value of that type that is otherwise indistinguishable would not be considered the same value. So when we say "A is B" in an algorithm step, for example, "is" would represent a different kind of comparison for values that carry identity than for values that do not. We all know that when we say _a_ is *true* that there are only 2 inhabitants of the Boolean type and any *true* value is the same as any other *true* value. That's not the case with some other spec values, and it is unclear for some.

[mhofman]

From the program's point of view (observable values), I have been thinking of terms of forgeable or unforgeable identity. A value has the same identity as another one if it passes Object.is (aka is === but differentiating -0). A value is forgeable if it can be constructed purely by syntax (or by access to intrinsics). Objects and unique symbols are obviously unforgeable. Strings, booleans, numbers, registered symbols are all forgeable (well-known symbols can also be considered forgeable since the program can grab them from a fresh realm). Records and tuples have composite identities, so they are "forgeable" from the values they contain. If they are composed only of forgeable value, they are like other forgeable values. If they contain one or more unforgeable value, their identity is forgeable as long as those unforgeable values are reachable to the program.

[ljharb]

Some examples in the spec would be:

• spec enums, like ~empty~, are like js strings
• mathematical values are like js numbers
• Lists are like js arrays
• Records are like js objects

I don’t really like the term “identity” here, because to me, everything has identity, it’s just that there’s only ever one 3 - all 3’s are the same 3. It is still useful to differentiate between these in some way.

[syg]

I don’t really like the term “identity” here, because to me, everything has identity, it’s just that there’s only ever one 3 - all 3’s are the same 3. It is still useful to differentiate between these in some way.

I strongly feel the other way, that identity is a well understood term to mean the property that distinguishes an "object" (in the metaphysical sense) from all other objects. While it is true there's a view that values like '3' have a degenerate identity in that the spec considers there to be a singleton "object" 3 in the universe, it's easier to just say that it doesn't have identity. There's only confusion to be had to split with the usual understanding of the "identity" term.

[michaelficarra]

@mhofman I'd like to keep this discussion focused on how the spec itself (as in, algorithm steps) observe and talk about identity. We can talk about how ECMAScript programs handle identity in a separate thread. Of course, ECMAScript language values are also themselves spec values, so we may nevertheless do some of that here.

@ljharb @syg I don't think it's necessary to come to an agreement on these two perspectives. For the purposes of this discussion, all that matters is deciding which of the two categories (that each of you have, though have separate understandings of) each kind of spec value belongs to. For simplicity, in this discussion I will continue to use "identity" in the typical way, as @syg uses it.