Editorial: define and use improved intrinsics notation

[ljharb]

Per editors' group discussion, separating this out from #1314.

The intention here is to prevent unbounded future growth of the intrinsics table, while also making intrinsic references slightly more readable/intuitive by making them more closely mirror the JS you'd use to access them (in an unmodified realm).

This ideally would be coupled with a change in ecmarkup to auto-link intrinsic syntax to the value in question, for even easier consumption.

Closes #1377. Closes #1105.

[jmdyck]

Rather than adding (for instance) i.e., %ArrayBuffer.prototype% in the third column ("ECMAScript Language Association"), I think it would make more sense to add %ArrayBuffer.prototype% in the first column ("Intrinsic Name").

[ljharb]

@jmdyck there are potentially other specs that reference the original intrinsic name.

[domenic]

The only such specs should be HTML, Web IDL, and Streams, which are all living and can be updated. So indeed, if you want to remove all %XPrototype% entries entirely, we could probably get away with that, with a bit of extra work.

[ljharb]

@domenic definitely; my hope is to land this, then I'll go file PRs on those specs to update them, and then I can come back here and file a final one to "clean up" all the no-longer-necessary explicit intrinsics.

[jmdyck]

@jmdyck there are potentially other specs that reference the original intrinsic name.

They can continue to do so, as I didn't suggest removing the original names. I specifically said add the new name to column 1.

[Ms2ger]

What's the status here?

[jmdyck]

Suggested change

<p>Within this specification a reference such as %name% means the intrinsic object, associated with the current realm, corresponding to the name. A reference such as %name.a.b% means, as if the "b" property of the "a" property of the intrinsic object %name% was accessed prior to any ECMAScript code being evaluated. Determination of the current realm and its intrinsics is described in <emu-xref href="#sec-execution-contexts"></emu-xref>. The well-known intrinsics are listed in <emu-xref href="#table-7"></emu-xref>.</p>

<p>Within this specification a reference such as %name% means the intrinsic object, associated with the current realm, corresponding to the name. A reference such as %name.a.b% means the object that is the "b" property of the object that is the "a" property of the intrinsic object %name%, before any ECMAScript code is evaluated. Determination of the current realm and its intrinsics is described in <emu-xref href="#sec-execution-contexts"></emu-xref>. The well-known intrinsics are listed in <emu-xref href="#table-7"></emu-xref>.</p>

[jmdyck]

Tangential thought for the future (not a problem for this PR):

@ljharb

my hope is to [...] come back here and file a final one to "clean up" all the no-longer-necessary explicit intrinsics.

Note that if you remove table rows for things that can be expressed as %Foo.X%, that will raise a question about the definition of "well-known intrinsic". There are currently two definitions: "built-in objects that are explicitly referenced by the algorithms of this specification", and "the objects listed in Table 7", and I think they currently agree. But if an algorithm references %Foo.X% and there's no row for %Foo.X% in Table 7, then the definitions disagree.

You could resolve it either way (i.e., pick either to become the "true" definition), but you'd need to alter the other so that it no longer sounds like a definition.

[jmdyck]

CreateIntrinsics creates _realmRec_.[[Intrinsics]] with a field for each intrinsic listed in Table 7, but this PR will allow specs to refer to intrinsics that are not listed in Table 7, so it's not clear how such references would be 'resolved' (in the specification model). It seems like [[Intrinsics]] would need a field for every intrinsic, whether listed in Table 7 or not, which will require some change of wording.

(This is related to a comment from @domenic in #1105.)