Which specifications are related to ECMA262

[dSalieri]

My question is based on a quote from the spec and answers of tc39 members from another question (#1703).

Quote from specification, section 6.1.7.4:

Well-known intrinsics are built-in objects that are explicitly referenced by the algorithms of this specification and which usually have realm-specific identities. Unless otherwise specified each intrinsic object actually corresponds to a set of similar objects, one per realm.

But as I could see, not all objects are used in the algorithms of the specification itself(as example Array.prototype.forEach).
To which I was given this kind of answer by @devsnek:

well known intrinsics are distinct because they're directly referenced in other specifications such as intl and html. we can move around a lot of internal stuff but they have to stay stable in relation to those specifications.

As well as a member @allenwb:

A well-known intrinsic is an intrinsic that is explicitly referenced by an algorithm or requirement of this specification or of a related specification.

Since the specification does not say that well-known intrinsic is not only an object that is used by the specification itself, the following questions therefore arise:

1. Why it is not specifed in the specification that a well-known intrinsic is also an object that can be used in related specification algorithms.
2. What specifications are related in this case (criteria or requirements in order to understand by what parameters it is possible to determine relatedness)?

[bergus]

I'll answer your second question: No, it is not possible to determine relatedness. Any other specification could reference the well-known intrinsics. It's just a tool that gives a constant identifier to certain objects in a JS realm, making them referenceable.

[allenwb]

And intrinsics typically gets added to the well-known list when the editor of another specification notifies the ECMA-262 editors that they need to reference those intrinsics.

[jmdyck]

And intrinsics typically gets added to the well-known list when the editor of another specification notifies the ECMA-262 editors that they need to reference those intrinsics.

That's how they typically used to be added, but I think %JSONStringify% (PR #1272) was the last such, and probably the last ever, now that PR #1376 has been merged. (E.g., the WebIDL editor, instead of asking for %MapProto_set% to be added to Table 8, can now just use %Map.prototype.set% without needing any change to the ECMAScript spec.)

[dSalieri]

@bergus and @allenwb got it, thanks for your answers.

---

@jmdyck was intriguing :) From your words, we can conclude that the table with well-known intrinsics will no longer be updated. Then the question follows, why then do we need in table with intrinsics?
And then why can %Map.prototype.set% just be used? Why's that? In the specification (if it was actually updated) there is not the slightest word or hint that any other specification may indicate well-known intrinsic even if it is not in the ecma-262 table. I read all of your links, but I still did not understand in which place it is specifically permitted to use well-known intrinsic which are not in the table. (It sounds really strange: well-known intrinsic which are not in the table)

[ljharb]

@dSalieri because #1376 made it so that any "original property" off of any well-known intrinsic can be accessed with dots - so only a "top-level" intrinsic object ever needs to be added. You may be looking for the second sentence of the second paragraph in this section: https://tc39.es/ecma262/#sec-well-known-intrinsic-objects

[dSalieri]

@ljharb I understood access through dots. But again, the specification does not mean that if you want to use in "your specification" then use dot notation. No, this is described within the ecma262 specification itself, how to use it internally. And then if you look at this second paragraph of what you are talking about, you can draw the following conclusion:
If another specification refers to an object that is not in well-known intrinsics, then it needs to use the dot notation that you mentioned. But this object will no longer be well-known intrinsic; it will be ordinary intrinsics. This implies the following conclusion, which I mentioned above: why then do we need in table with well-known intrinsics?

[jmdyck]

From your words, we can conclude that the table with well-known intrinsics will no longer be updated.

No, it will still be updated, but probably only for new intrinsics. E.g. PR #1515 added the %BigInt% intrinsic to the table.

In the specification... there is not the slightest word or hint that any other specification may indicate well-known intrinsic even if it is not in the ecma-262 table. I read all of your links, but I still did not understand in which place it is specifically permitted to use well-known intrinsic which are not in the table. (It sounds really strange: well-known intrinsic which are not in the table)

I don't think the ES spec itself has ever stated what related specifications can or cannot reference from the ES spec. (Or should/should not. Or what form such references can take.) Nothing is specifically permitted or specifically disallowed.

So, for example, when the Infra spec requested that %JSONStringify% be added to the table, they didn't have to; they could have said something like:

Let _JSONStringify_ be the initial value of the "stringify" property of the %JSON% intrinsic defined in the ES spec.

and then proceeded to use _JSONStringify_. It would have meant the correct thing, and it would have been understandable to its readers. There might even be examples in the wild of such indirect references to ES intrinsics, I don't know.

The idea that ES intrinsics should only be referenced directly, and thus require an entry in Table 8 in order to be referenced, isn't something you'll see stated officially. I think it's more of an understanding among TC39 + environs. And #1376 changed that understanding, so that it's now okay to use the dot notation to reference intrinsics that don't appear in Table 8. (Or at least, it's a step in that direction. It'll be clearer when the actions that @ljharb describes here happen.)

[dSalieri]

@jmdyck hmm. It now looks like a hybrid concept with well-known intrinsics. And the table, as it were, is not deleted, but it is also updated as you said in special cases (although @allenwb didn’t say anything about this above, and from his words, as I understand it, the addition of new well-knowns depends on the request of third-party specifications here). And in order to use well-known intrinsics that are not in the table in any specification (although in fact they are just intrinsics, since they are not in the table), you need to use dot notation to follow the rules.

Although, as I understand it, @allenwb is against deleting the table as a whole, as a concept of the well-known intrinsics themselves and also against operations with specification devices that are not agreed with ecma262. If dotted notation is agreed action on specification devices, then fine. But I am not sure in it.

@allenwb is dot notation in this case a contradiction in the existence of a table well-knowns?

[ljharb]

Yes, dotted notation is what's intended to be used everywhere from now on. Once I've updated known related specs, I'll put up a PR to remove the unused intrinsics (ie, %ArrayProto_values% which can now be %Array.prototype.values%).

[dSalieri]

@ljharb dotted notation is agreed action on ecma262 specification devices for related specifications?

[ljharb]

I won’t know for sure until i make the PRs, but i can’t imagine why not, and an editor of the html spec seemed on board on the 262 PR.

[dSalieri]

@ljharb I understood you. Although yes this is a formalized entry proposed by ecma262, then there are no complaints. It looks like you mean the editor as a person and not as an application. But what did you mean by this part of the sentence: and an editor of the html spec seemed on board on the 262 PR.

[ljharb]

I mean that one of the humans who has the position of “editor” of the html spec seemed like they were in favor of the change.

[dSalieri]

@ljharb Now completely clear. Thanks for quickly answer.

[ljharb]

Do you think your question has been answered, and this can be closed?

[dSalieri]

@ljharb I think yes.